From prototype to production: the missing layer in enterprise AI

Most large organisations now have a folder of impressive prototypes. Something that summarises contracts. Something that scores leads. Something that replaces a reporting pack. Very few of them are in production, and the reason is rarely the quality of the idea.

A prototype demonstrates that a problem is solvable. Production is a different claim: that the solution can be trusted with real data, real users and real consequences, on a Tuesday, when its author is on holiday.

What the production layer contains

• Identity: single sign-on against the corporate directory, not a separate password list.
• Authorisation: roles and permissions that mirror how the business is actually organised, enforced on the server rather than hidden in the interface.
• Data isolation: strict separation between clients, entities or business units, verified rather than assumed.
• Integration: real connections to the systems of record, with error handling for the days those systems are unavailable.
• Data architecture: a schema that survives the second and third requirement, plus migrations that can run without downtime.
• Auditability: who did what, when, and on what basis — particularly where an AI model influenced the outcome.
• Observability: logging, alerting and a defined path from an error to the person who fixes it.
• Release control: environments, review, rollback, and a deployment process that does not depend on one individual.
• Ownership: source code in the company's own repository, documented well enough for another team to take over.

The demo answers 'can this work?'. Production answers 'what happens when it does not?'.

Why AI makes this layer more important, not less

AI-assisted development compresses the visible part of the work, which widens the gap between what exists after a week and what can be deployed. It also introduces failure modes that traditional applications do not have: non-deterministic output, model behaviour that changes when a provider updates, and decisions that need a human record of reasoning.

An AI feature in an enterprise workflow therefore needs boundaries: what the model is allowed to decide, what requires confirmation, what is logged, and what happens on a low-confidence answer. Those boundaries are design decisions, not model settings.

How we approach it

We build the prototype fast, deliberately. Then we treat the move to production as its own explicit step with its own checklist, rather than an optimistic continuation of the same momentum. It is the least glamorous part of the work and the part that decides whether anything reaches a user.