Home · AI
AI delivery and governance
Building with AI is now the easy part
A senior engineer with AI can now produce in a week what used to take a quarter. What has not changed is who decides the rules, who reviews the output, and who answers for it in production. That gap is where the next round of technical debt is being created, and it is the part we work on.
Our position
Ungoverned AI delivery will cost more than the waves before it
Every previous acceleration in software, from fourth-generation languages to low-code, produced the same pattern: output rose faster than the ability to review it, and the gap turned into maintenance cost three years later. AI-assisted development follows the same curve, with two differences that make it heavier. The volume is larger, and the person who produced the code cannot always explain why it is written the way it is.
What we observe on real projects is not that the code is bad. It is that nothing constrains it. Two engineers on the same codebase, prompting the same model in the same week, produce screens that behave differently, naming that diverges, and patterns nobody chose. Left alone for a quarter, a team ends up with a system that works and that no one can reason about.
The second failure is slower and harder to reverse. An AI system reads what your organisation stores. If the data is stale, duplicated or undocumented, the output degrades, and that output is then stored and read by the next iteration. The errors become the source. Data governance is not a parallel workstream to an AI programme, it is the thing that stops the programme decaying.
What actually goes wrong
Four failures we see, in this order
- Divergence, within weeksWithout a written convention that the model is made to re-read, output drifts. Screens stop resembling each other, the same concept gets three names, and the cost lands on whoever maintains it. The fix is cheap at the start and expensive after the fourth module.
- Code in production nobody reviewedThe question is not whether a model writes good code. It is whether an organisation can state who reviewed what before it reached a system that moves money or goods. Most cannot, and their audit function has not asked yet.
- Security debt that arrives silentlyGenerated code pulls in libraries, and libraries carry vulnerabilities. Without scanning in the loop, a project inherits a dependency tree nobody chose and no one is watching. This is mechanical to solve and almost never set up at the start.
- The data degradation loopModel output becomes input. Without freshness, lineage and ownership on the data underneath, quality falls over successive iterations, and the decline is invisible until a business decision is visibly wrong.
From our own delivery
Ten years of internal tooling, rebuilt as a prototype in two months
One of our senior consultants, embedded for years on the integration platform of a global container shipping group, rebuilt its entire operating console with AI assistance: setup management, versioning, quality control, packaging, graphical workflow editing and production monitoring. Frontend, backend, database procedures and APIs. Two months, one person.
He had spent years inside the platform's data model, its business rules and its failure modes. Asked whether an outside developer with the same tools could have done it, his answer was no: the tools were available to everyone, the context was not.
Every validated screen produced a rule, recorded in project documentation rather than left in a chat history. The model re-reads that documentation before touching the next screen, which is what keeps twenty screens looking like one product.
Content-addressed versioning, immutable released objects, and a quality check that blocks packaging when the rules are not met. A good practice that can be skipped is a suggestion. The same rule in the pipeline is a control.
Static analysis, secret detection, dependency and coverage scanning in a container, the report fed back for remediation, and a second review from a clean context with no project history. A dependency CVE and a thread-safety flaw were found and fixed this way.
This system is a prototype under test, not a production deployment, and it has not yet been through the client's own security review. We describe it because of what it shows about method, not to claim a production reference. The client is not named.
How we help
We build the solution, and the frame it runs inside
Most of this work is not model work. It is the engineering and organisational scaffolding that lets a team move fast with AI without producing something nobody can maintain, audit or defend.
AI delivery framing
Conventions, naming, architecture rules and a definition of done, written as documentation the model is made to re-read rather than as a slide nobody opens. Plus the arbitration of what is delegated to a model and what is not.
- Conventions
- Architecture rules
- Definition of done
- Prompt and context discipline
Review and security of generated code
Static analysis, secret scanning, dependency and vulnerability tracking, coverage thresholds, and an adversarial second review run from a clean context. Set up as a pipeline, not as a one-off audit.
- SAST
- Secret scanning
- SCA and CVE tracking
- Adversarial review
Solution architecture and integration
The part that decides whether a prototype becomes a system: data model, APIs, packaging, environments, migration and the interfaces to what you already run. Our founding discipline, applied to AI-assisted builds.
- Data model
- API design
- Packaging and environments
- Legacy integration
Data governance for AI
Freshness, lineage, ownership and reference data on the flows an AI system reads, with stated service levels on data age and error rate. This is what stops output quality decaying over successive iterations.
- Freshness SLAs
- Lineage
- Reference data
- Quality monitoring
Compliance and sovereignty
Where the models run, where the data rests and transits, what an AI system may read, and the evidence a regulator or an internal audit will ask for. Under the AI Act, DORA and NIS2, with a European hosting option when the perimeter requires it.
- AI Act
- DORA and NIS2
- European hosting
- Audit evidence
Team enablement
The skill that matters now is not the framework. It is knowing the business well enough to judge what the model produced. We work alongside your engineers, transfer the method, and leave the conventions behind us.
- Pair delivery
- Method transfer
- Review practice
- Documentation
How we engage
Start on one real perimeter, not on a policy
5 to 15 days. What your teams already build with AI, what reaches production, what is reviewed, and where the exposure sits. Ends with a costed plan.
Conventions, review pipeline and quality gates on one real perimeter, so the rules are tested against actual delivery rather than written in the abstract.
A bounded solution delivered with AI assistance, inside that frame, with the architecture and integration work that makes it maintainable.
Your engineers run the method without us. Conventions, pipeline and documentation stay with you.
Your teams are already building with AI.
The question is what happens to that code in eighteen months. A 5 to 15 day assessment tells you where you stand and what it will cost to put a frame around it.