By Mihaly Fodor (ERNI Romania)
In my last article, I described what it took to move Claude Code from clickable demos to a real production project. The short version: the AI is fast on small, well-framed tasks. The control around it is where the real work lives. By writing design documents, I aimed to keep scope narrow, split planning from implementation and put every change on its own feature branch. I merged only when the full end-to-end suite was green and I had checked it by hand. That discipline is what made everything work. It was also entirely mine to drive, one prompt and one review at a time, and did not scale to an organisation level.
That leaves an obvious question. If control is the hard part, what would it look like to have the platform enforce it at organisational scale? That is the challenge the ERNI AI Factory sets out to solve. The cleanest way to explain it is to walk through the layers and ask, for each one, why it needs to exist.
Production introduces four uncomfortable questions
Most companies do not struggle to build a first AI demo. They struggle with everything around it. Who is allowed to use it? What data is the system/tool allowed to see? What does it cost? What did it do last week? When every project answers those four questions on its own, the results are inconsistent, expensive to build, and impossible to audit. A demo skips all four. Production cannot.
Governance should be inherited, not rebuilt
The Factory’s premise is that those questions should be answered once, as shared infrastructure. Every AI use case then inherits login, access control, cost limits, audit logging and tracing on day one instead of rebuilding them. The Factory is built as four horizontal layers: use cases, intelligence, security and compliance, and data harmonisation (Figure 1). Requests flow down, data flows up, and each layer has exactly one job.
The use case should be deliberately powerless
The use cases layer is deliberately thin. A use case is what the user touches: a chat window, an approval screen, a coding assistant. In the Factory, it is powerless by design. It handles the user interaction and passes everything else down. That is the whole point. Adding a use case never means adding governance code, because the use case has none to add. It cannot create an identity. It holds no model key. It cannot reach the data on its own. A badly written use case therefore cannot grant itself more than it was given.
The intelligence layer is the collection of agents that interpret a request, retrieve material and compose an answer. Agents call language models constantly. What they never do is call one directly, and the reason is not etiquette. The Intelligence layer holds no model credentials at all. It physically cannot reach a model except through the layer below that holds the keys. Governance is enforced by who holds which credential, not by who remembers the rule.
Security and compliance is the heart of the Factory. It is the guard that sits between intelligence and everything valuable. It verifies identity and permissions. It attributes and caps cost. It records every decision. The important choice is that it is a single control point. There is one door, and everything on the request path goes through it. Because there is only one door, a new use case is governed automatically: there is no other path to a model or to data. And because the guard holds no per-request state, it is designed to run as several identical instances behind a load balancer, so one control point need not mean one point of failure.
Data harmonisation, the bottom layer, keeps the agents away from the raw sources. It connects to the systems that hold information, for example, SharePoint, Jira and Git, transforming their content into one internal format the agents can query. In our reference implementation, this means one document corpus and one code analysis adapter. Agents ask this layer for material and never talk to the raw sources themselves. The services that hold that data sit on a network with no route to the internet. Even if an agent misbehaves or a model emits harmful instructions, there is nowhere to send data out. That is data that cannot phone home, enforced at the network level, not by policy.
Assume that something will eventually fail
Underneath the layers sit four boundaries. The layers describe responsibilities; the boundaries describe how those responsibilities are contained. Together, they prevent failure in one part of the system from becoming a failure everywhere.
These are an identity boundary that every hop re-checks, a network boundary that the data plane cannot cross, a capability boundary that limits credentials, and a single guarded exit for the coding sandbox.
The reason there are several rather than one is that each is designed to hold even if another is bypassed. If a use case is compromised, it still holds no model or data credentials and sits on no privileged network. It gains nothing it could not already have asked the guard for. If the identity check is somehow defeated, the network isolation still denies the data services any route to the outside. No single failure opens a path from an untrusted actor to private data or an ungoverned model. The layering exists for that reason. It is not decoration.
AI autonomy needs a controlled ladder
The same core supports four kinds of use cases. They differ only in how much freedom the AI gets and where the human sits. They form a ladder. A client can start on the rung that fits today and climb from there. The four rungs are chatbot, workflow, AI-assisted SDLC, and AI-native development.
A chatbot answers questions from governed documents with citations, with every question tied to a real logged-in person. A workflow puts AI inside a business process. The AI drafts, and a human approves. The approval rule is enforced on the server, so a member who tries to approve their own draft is refused no matter what buttons the interface shows.
Does verification have to depend on the agent’s word?
AI-assisted SDLC is developer mode. You open your real project in your normal editor inside an isolated sandbox. Version control and secrets stay outside it. By default, every AI tool inside it points at the same governed exit. Your day-to-day AI use is budgeted, attributed and logged like everything else.
AI-native goes one step further. One command runs a coding agent against a written request with no human in the loop. It then reruns the project’s own tests inside the sandbox and labels the change verified or unverified based on what the tests say, not on what the agent claims. The tests are the gate. The harness demonstrates that core mechanic. Whole applications designed around AI end to end remain the roadmap.
That is exactly the discipline I had to supply myself on previous projects: never trust the agent’s report that «the tests passed» – verify against a real green suite before merging. Here it becomes a property of the platform. Two honest limits stay in view, because pretending otherwise would repeat the failure mode I wrote about last time. A verified label on an empty change only proves the existing tests still pass, not that the requested work was done. And the harness asks the agent not to edit the tests but does not yet enforce that technically. Those are named next steps, not hidden assumptions. The earlier sections describe where governance lives; the next two mechanisms show how it operates in practice: cost control and accountability.
Cost is metered per identity at the gateway where the models are called. When a budget is spent, the next call is refused outright, with a name attached. That is a hard limit, not a best-effort tally in the application. And every significant action, denials included, writes a record to an append-only audit log: who acted, what kind of action, when, and what it cost. The log stores metadata only – no prompt or answer text. That keeps it useful for accountability without becoming a second copy of all your content. The Factory enforces rather than observes.
Conclusion
My projects have taught me that an AI tool is only as reliable as the controls around it. The Factory’s premise is that those controls should be built once into the platform, so every use case inherits them, and no team has to remember to recreate them. The demo is the easy 20 percent. The Factory builds the other 80 percent into the system itself.
