Perspectives on enterprise AI

Modernisation  ·  6 min read

The real cost of AI modernisation: what your estimate is missing

When organisations build the business case for a modernisation programme, they typically account for three categories of cost: the people required to execute the work, the technology licenses and infrastructure needed to support it, and the time it will take. These are the visible costs — the ones that appear in proposals, get challenged by procurement, and end up in board papers.

What most estimates do not account for is the fourth category: the AI governance overhead that the modernised environment will require. Not because this overhead does not exist — it is very real and very significant — but because it has not historically been part of how modernisation programmes are scoped.

The EU AI Act, ISO/IEC 42001, and the NIST AI Risk Management Framework all impose operational obligations on AI systems that did not exist when most modernisation estimation practices were developed. EU AI Act Article 9 requires risk management systems for high-risk AI applications. ISO 42001 mandates an AI management system — not a document, but an operational capability. NIST AI RMF expects governance to be continuous and measurable. Each of these obligations translates into real effort: people, tooling, and time that must be factored into the programme budget.

What to add to your estimate

Based on programmes AyronLegion has designed and delivered, governance overhead in AI modernisation programmes typically falls into four categories. Compliance architecture — the work of designing the governance model for the modernised environment — adds between five and twelve percent to early-phase effort, depending on the regulatory complexity of the organisation. Governance tooling — the implementation and configuration of continuous monitoring, evidence generation, and reporting capabilities — adds a further implementation cost that most estimates treat as infrastructure but is better understood as a compliance capability investment.

Documentation obligations — the ongoing requirement to maintain evidence of governance decisions, model characteristics, and system behaviour — add operational overhead that needs to be staffed and sustained. And compliance transition management — ensuring that the organisation remains compliant during the migration, not just after it — requires dedicated effort that is often absent from modernisation programmes entirely.

These are not theoretical costs. They are the costs that materialise when organisations discover, mid-programme, that their modernised environment is not compliant with the obligations that took effect while they were migrating. Building them into the estimate before the programme starts is not conservative budgeting. It is accurate budgeting.

Application Development  ·  7 min read

Spec-Driven Development: why definition matters more than delivery speed

The most common measure of development team performance in enterprise organisations is velocity — how much gets shipped, how quickly. Velocity is a useful metric. It is also an incomplete one. A team that ships fast but ships software that cannot be governed, audited, or maintained by anyone other than the original developers has not delivered value — it has delivered liability.

Spec-Driven Development is not a new idea. The principle that software should be precisely defined before it is built — and that those definitions should serve as the basis for testing, compliance validation, and maintenance — predates modern software engineering by decades. What is new is the regulatory environment that makes the principle urgent rather than merely sensible.

The EU AI Act requires that high-risk AI systems be documented to a degree that allows competent authorities to assess compliance. ISO 42001 requires that AI management systems maintain documentation of AI system characteristics, training data, and operational constraints. NIST AI RMF expects that the behaviour of AI systems be understood, documented, and verifiable. These requirements are not satisfied by a backlog of user stories and a deployment log.

What specification enables

A specification — a precise, reviewable definition of what the software does, how it behaves, and what constraints it operates within — enables five things that user stories and backlogs do not. It provides the basis for test cases that validate behaviour rather than implementation. It provides the evidence that compliance review requires without additional documentation effort. It provides the foundation for maintenance by any competent team, not just the original developers. It provides the mechanism for assessing the compliance implications of proposed changes before they are made. And it provides the audit trail that regulated organisations are required to maintain.

The investment in specification is not overhead. It is the investment that makes governance possible without adding a separate compliance workstream alongside the development. Organisations that build to specification spend less on remediation, pass compliance reviews faster, and maintain their software at lower cost over time. The fastest path to compliant, maintainable software is not to move faster and add governance later. It is to define precisely, build to definition, and govern as you go.

Regulatory  ·  10 min read

The EU AI Act is in force. Is your AI programme ready?

The EU Artificial Intelligence Act entered into force on 1 August 2024. Its obligations are not uniform — they apply differently depending on the risk classification of the AI system in question — but for organisations operating in the EU, selling to EU customers, or processing EU data with AI systems, the question is no longer whether the Act applies. It is whether the organisation is meeting its obligations.

The most significant obligations under the Act apply to high-risk AI systems — a category that includes AI used in critical infrastructure, employment decisions, credit assessment, biometric identification, and several other domains that are common in enterprise AI deployments. For high-risk systems, the Act requires a risk management system, data governance practices, technical documentation, transparency measures, human oversight capabilities, robustness and accuracy testing, and a conformity assessment before market placement. These are not aspirational standards. They are operational requirements with enforcement consequences.

What organisations need to have in place

For organisations with high-risk AI systems, AyronLegion recommends a structured response organised around five priorities. The first is classification — understanding which AI systems in the organisation's portfolio fall within the high-risk categories defined by the Act, and which additional systems may be brought into scope as the Act's scope evolves.

The second is documentation — establishing the technical documentation requirements for each high-risk system, including system architecture, training data characteristics, validation testing results, and ongoing performance monitoring records. The third is risk management — implementing the risk management system required by Article 9, with documented risk assessments, risk controls, and residual risk acceptance records.

The fourth is human oversight — designing and implementing the human oversight mechanisms required for each high-risk system, with documentation of how oversight is exercised and by whom. The fifth is ongoing monitoring — establishing the post-market monitoring systems required to track system performance against the characteristics documented at the time of conformity assessment.

For organisations that have not yet begun this work, the starting point is an honest assessment of which AI systems are in scope and what the gap is between current governance practice and the Act's requirements. That assessment is the foundation for a realistic programme — one that meets the obligations, generates the evidence, and does not create remediation debt that will be more expensive to address later.