Six things an enterprise
AI platform needs

One of the lessons I learned building KFactory came well before generative AI became a boardroom topic. In one of our early deployments, we started with two industrial presses. There was no dramatic reveal. We connected the equipment, made the data dependable, built a workflow operators could actually use, and made the results visible to the people responsible for production.

Six months later, the customer expanded the pilot. Over time, KFactory was supporting 45 pieces of equipment. That experience stayed with me because it is a good reminder of how technology earns its place in operations: gradually, through usefulness, clarity and reliability.

AI is facing the same test now.

A chatbot can be an excellent interface. It makes complex technology approachable and gives people a natural way to ask for help. But the moment AI moves from helping one person draft an email to supporting production, planning, maintenance, quality, customer service or finance, the chat window becomes only the visible layer.

The real platform is everything behind it: operational data, the systems that do the exact work, permissions, evidence, human decisions and cost controls.

While building KFactory and speaking with operations and IT teams, I keep coming back to six questions. I find them more useful than the latest model leaderboard because they tell me whether an AI system is ready to become part of daily work, not just a convincing demo.

01. Can it work with operational data without turning the prompt into the database?

Useful operational questions are rarely about one page of text. They are more likely to be: Which orders are at risk this week? What caused the repeated stops on this line during the last three shifts? Which maintenance actions should we prioritise across all sites?

The answer may sit across millions of records in production systems, ERP, maintenance applications, documents and equipment data. The tempting shortcut is to export that information, split it into chunks and keep feeding it to a language model. That can work in a small experiment. It is not how I would want to run an important process.

A language model is useful here, but it needs the right job. It can understand the request, identify the relevant sources, choose a permitted tool, create a plan and explain the result. The database, analytics engine or planning solver should still do the exact calculation. The model does not need every raw row in order to be useful.

This is close to how we think about governed agents at KFactory. The agent coordinates the work. Data access and repeatable, rule-based execution stay inside controlled operational systems. Only the minimum context required for the next step returns to the model, and access is recorded.

The 2023 Samsung incident is a useful reminder of why this matters. After sensitive code was uploaded to ChatGPT, Samsung temporarily restricted public generative AI tools on company devices. The lesson is not that employees cannot be trusted. It is that people need a safe, approved route to use AI with company information. If the only practical workflow is copy and paste, eventually somebody will copy and paste something they should not.

A good platform therefore keeps the computation close to the source, moves only what the task requires and makes it clear which systems were consulted.

02. Can every important answer be traced back to evidence?

When an experienced plant manager asks, “Where did this number come from?”, I do not see resistance to AI. I see good management.

People who run operations know how easily context changes a result. The time window may be wrong. A sensor may have been unavailable. A document may be out of date. A filter may have excluded one site. A planning constraint may have been misunderstood. A confident paragraph does not make any of those possibilities disappear.

By traceability, I do not mean asking the model for a longer story about how it reached an answer. That is not reliable evidence. What matters is a record a person can inspect: the documents and versions used, the query or tool that produced the result, the workflow steps and timestamps, and the approvals or actions that followed.

That record does three jobs. It helps an expert decide whether to trust the result. It helps a team diagnose an error before it spreads. And it gives the organisation something defensible when a customer, auditor, regulator or board member asks how a decision was made.

Mata v. Avianca and Moffatt v. Air Canada are useful examples because both make the same point from different directions: fluent output is not proof. The organisation remains responsible for checking the information it uses.

At KFactory, that is why source references, audit trails and reproducible workflow steps are part of the answer rather than an optional technical log hidden somewhere else. Most users should not have to study the detail every time. But when somebody needs to verify, improve or defend a result, the evidence should be there.

03. Can the business choose where it runs and change the model when needed?

There is no virtue in “cloud” or “on-premise” by itself. The right answer depends on the business: data residency, customer commitments, network constraints, availability, latency, cost and risk all matter.

For some companies, cloud SaaS is exactly the right choice. It is fast to deploy and simpler to operate. For others, the process needs to run in a private cloud, inside the company’s own environment or, in some cases, in a tightly isolated network.

The important part is not to force every process into one architecture. The platform should make the choice explicit and explain the trade-offs.

I think the same way about the model itself. Models improve, prices change and commercial terms move quickly. A critical process should not need to be rebuilt every time the preferred model changes. The workflow, permissions, data connections, rules and audit trail should remain stable while the model can be configured or replaced.

This is why KFactory supports cloud SaaS as well as on-premise and private-cloud deployment, and why the model in our Intelligence architecture is a configurable component of a governed platform rather than the foundation of the entire workflow.

Italy’s temporary limitation on ChatGPT in 2023 was a useful reminder. The lasting lesson is not that one provider or one jurisdiction is uniquely risky. It is that a process tied to a single external endpoint also inherits that endpoint’s legal, commercial and availability risk.

04. Are there clear boundaries on what the AI may read, say and change?

An enterprise agent needs something very close to a job description.

A maintenance agent may need machine history, work orders and technical documentation. It does not need payroll data. A customer-service agent may explain a policy, but it should not invent a price or approve an exceptional refund. A quality agent may prepare a corrective-action draft, but a named person may still need to close it.

Those boundaries have to exist at several levels. Identity and data controls should enforce role-based access and least privilege. Inputs need protection against prompt injection, hidden instructions and untrusted content. Outputs may need validation for accuracy, policy, safety, tone or required disclosures. Actions need explicit permissions, transaction limits, approved tools and safe failure behaviour.

The key point is that these are platform responsibilities. They should not depend on every developer remembering a checklist or on a sentence in a prompt politely asking the model to behave.

The Chevrolet dealer chatbot that generated a one-dollar Tahoe “offer” is an easy incident to visualise. No vehicle was sold and the text was not established as a binding contract, but the exchange showed how easily a user can override weakly defined instructions. The iTutorGroup case showed the higher-stakes version of the same problem: automation can apply the wrong rule or authority at scale.

A useful agent has room to work. A trustworthy agent also knows exactly where that room ends.

05. Is human approval a real workflow step rather than a polite instruction?

I do not find the question “Should AI be autonomous?” very useful. Autonomy is not a switch. It is a dial, and the right setting depends on the risk, reversibility and maturity of the process.

A sensible progression is to let the agent first observe and organise information. Then it can recommend an action and show the evidence. Next, it can prepare an action for approval. Only after the process is understood and measured should it execute low-risk, reversible work inside clearly defined limits.

For anything that affects safety, money, customer commitments, production records or other consequential outcomes, approval should be a technical gate. The workflow pauses. An authorised person reviews the evidence. The system records the decision. The agent cannot simply route around the gate because another instruction told it to continue.

The public Replit database incident in 2025 illustrated the difference. During a development experiment, an AI coding agent deleted live database records despite a stated code freeze. The data was later restored, and Replit introduced stronger separation between development and production databases.

The useful lesson is architectural: if an action matters, the system should make the unwanted action impossible or require an authorised person to release it.

At KFactory, human approval gates are part of multi-agent workflows for critical decisions. The aim is not to slow down every task. It is to put a person at the points where judgement, accountability or business authority are genuinely required.

06. Is the cost visible, measurable and bounded?

The cost of an AI agent is not simply the price of one answer. It is the price of what the agent may decide to do next.

It can retry a failed step, call several tools, use a more expensive model, create sub-tasks or keep a loop running longer than expected. None of that makes agentic AI a bad investment. It means cost control has to be designed into the workflow, not discovered in the invoice at the end of the month.

Before a large task runs, I want to know the expected cost range, the maximum number of steps and retries, which model will be used for each part, what budget applies, and which conditions cause the workflow to stop, downgrade or ask for approval.

Hard caps are useful, but they are only part of the answer. A mature platform also needs alerts, rate limits, timeouts, model routing, cost attribution and a way to compare spend with the value of the result.

In 2026, public reporting said Uber used its annual budget for AI coding tools within four months and later introduced monthly usage limits. The details are specific to one company, but the broader lesson travels well: adoption can scale faster than the financial controls around it.

A budget is not a brake on innovation. It is what makes adoption sustainable and gives a team a way to compare the value created with the money spent.

The platform is what earns the trust

None of these six points is an argument against chatbots. A good conversational interface can make complex systems much easier to use, especially for people who do not need another dashboard or another technical language to learn.

But the interface should simplify the work, not hide how the work is governed.

At KFactory, our aim is to take repetitive, rule-based and analytical work away from operations teams so people can focus on decisions that need a person in the room. For that to happen, the agent has to do more than sound intelligent. It has to work with the right data, use the right tools, show its evidence, respect its permissions, stop for approval and operate within a known cost.

If I were evaluating an enterprise AI platform, I would start with one real operational process and ask six questions:

A platform that can answer those questions clearly is not asking you to trust a model because it speaks confidently. It is giving you practical reasons to trust the system around it.

That is how AI moves from an impressive demo to dependable daily work.

Adrian Dima
Co-founder & Product Lead, KFactory