Prerequisites and Readiness for Enterprise AI
Most organisations that struggle with AI do not fail at modelling. They fail because they committed budget to industrialising AI before their data, platform, governance, skills or culture could carry the load. This chapter gives a structured way to judge readiness before the money is spent, against the standard that Chapters 3 and 4 have set. It examines six dimensions, draws out the requirements specific to public authorities, and codifies the assessment as a scorecard that lives in version control. The approach extends the readiness guide in Architecture as Code (Chapter 26A), which asked the same question of architecture practice in general (66, Nordqvist, 2025).

Figure 5.1: Readiness is assessed across six dimensions (data, platform, governance, skills, cultural readiness and, for public authorities, the mandate), recorded in a scorecard under version control and tested against a minimum score before the platform is industrialised.
Why readiness comes before budget
Paleyes, Urma and Lawrence (2022) found that difficulties in published machine learning deployments cluster at every lifecycle stage, from data management to deployment, trust and security (55, Paleyes et al., 2022), and Sculley et al. (2015) that the model code is a small fraction of a production system (48, Sculley et al., 2015). The difficulties lie in the organisation around the model. In the pattern I see, a pilot succeeds because a motivated team worked around every missing prerequisite by hand, is approved for scale, and the workarounds collapse. The readiness assessment makes them visible before the scale decision: it is not a maturity ranking but a list of the things that will break.
Data readiness
Data readiness is the dimension most often overestimated, because every organisation has a great deal of data and very few have data ready to train or ground a model.
Ownership comes first: named data owners with a documented mandate and stewards who maintain quality are the minimum, and where Architecture as Code introduced data products as versioned artefacts with owners and contracts (66, Nordqvist, 2025), AI adds that the contract states what the data may be used to train. Quality and lineage come next, because a model inherits the defects of its training data and conceals them behind a confident output. For high-risk AI systems this is a legal requirement: Article 10 of Regulation (EU) 2024/1689, the AI Act, requires training, validation and testing datasets to be subject to data governance covering collection, preparation, assumptions, bias examination and gaps, and to be relevant, sufficiently representative and as free of errors as possible (1, European Union, 2024). An organisation that cannot describe its datasets to that standard is not ready to build a high-risk system, whatever its modelling talent.
Finally, the General Data Protection Regulation applies in full to training and inference: Article 5 sets purpose limitation, Article 6 requires a lawful basis for each purpose, Article 9 restricts special categories, and Article 35 requires a data protection impact assessment (DPIA) where high risk is likely (2, European Union, 2016). Training a model is a new purpose, so the question is whether a lawful basis for it has been established or merely assumed.
Platform readiness
Platform readiness needs three capabilities: compute and separate environments provisioned through infrastructure as code; workload identities with least-privilege access for models, pipelines and agents, because an agent running with a developer's credentials is an incident waiting to be logged; and existing observability, because AI quality monitoring sits on top of logging and tracing. Architecture as Code called this foundation the architecture runway (66, Nordqvist, 2025), and for AI it also needs a model registry and an evaluation pipeline. The governance test is simple: can the organisation say, for any model it intends to run, which version is approved, who approved it and on what evidence? If not, the platform is not ready, however much compute it has.
Governance readiness
Governance readiness is most often underestimated, because governance seems something to add later; yet the AI Act assigns obligations from the moment a system is put into service.
Risk appetite and accountable roles
An organisation needs a stated appetite for AI risk, named business, technical and oversight owners for each AI system, and knowledge of which AI Act role it occupies for each. Article 26 obliges deployers of high-risk systems to assign human oversight to natural persons with the competence, training and authority to exercise it, to monitor operation and to keep logs (1, European Union, 2024); if nobody can say who those persons are, governance readiness is zero regardless of how many policies exist.
A management system, not a committee
ISO/IEC 42001 defines an AI management system: the policies, objectives, processes, roles and controls through which an organisation governs its AI, with an annex of controls covering the lifecycle, data and third parties (32, ISO/IEC, 2023). Readiness does not require certification, but it does require an inventory of AI systems, an impact assessment process, documented responsibilities and continual improvement, which Chapter 9 codifies.
Impact assessment capability
The European Commission's High-Level Expert Group on Artificial Intelligence set out seven requirements for trustworthy AI, which Chapter 10 takes as its design frame (12, AI HLEG, 2019), and its Assessment List for Trustworthy Artificial Intelligence (ALTAI) turns them into a self-assessment questionnaire (13, AI HLEG, 2020). An organisation is governance-ready when it can run ALTAI, a DPIA and, where required, a fundamental rights impact assessment as a routine process with a known owner and turnaround.
Two instruments build on UNESCO's Recommendation on the Ethics of Artificial Intelligence of 2021, the first global standard on AI ethics (29, UNESCO, 2021). The Readiness Assessment Methodology (RAM) assesses a state's preparedness across legal, social, economic, educational, scientific and technological dimensions, and more than seventy countries have completed or started one (30, UNESCO, 2023); it describes the national context an organisation inherits. The Ethical Impact Assessment (EIA) is its system-level companion (31, UNESCO, n.d.) and sits beside ALTAI and the DPIA. This chapter's scorecard fills the organisation-level gap between them.
Worked example: a use-case intake form
Illustrative example. Impact assessment becomes routine when every proposal enters through the same short form, whose answers decide which assessments and which forum apply. Nordvik Region's form, for a proposal from its benefits unit, follows.
# intake/UC-2026-017.yaml - Nordvik Region (illustrative)
apiVersion: ai-architecture.example.org/v1
kind: UseCaseIntake
metadata:
id: UC-2026-017
submittedOn: 2026-09-08
businessOwner: head-of-benefits-operations
proposal:
title: Summarise incoming correspondence on open benefit claims
intendedPurpose: Draft a one-page summary of new correspondence for the caseworker
outOfScope: [recommending outcomes, contacting applicants, ranking claims]
expectedBenefit: 12 minutes saved per claim; measured over a three-month pilot
screening:
affectsIndividuals: true
decisionInvolvement: prepares-information-for-human-decision
specialCategoryData: possible # medical certificates in attachments
annexIIICandidate: point-5 # access to essential public services
agentActions: none
legalMandateConfirmed: pending
routing:
provisionalClass: high-risk-candidate
assessmentsRequired: [dpia, fria, altai]
reviewForum: ai-design-authority
readinessDependencies:
- data: correspondence archive has no named data owner
- publicSector: legal mandate for processing attachments to be confirmed
The screening answers are factual rather than evaluative, so the classification follows from them, and the readiness dependencies stop a proposal passing intake while it depends on an unmet prerequisite. Chapter 13 describes the design authority that receives the form.
Skills readiness
Skills readiness is about breadth more than depth. A handful of excellent data scientists is not a readiness signal; what counts is a workforce that understands what AI can and cannot do, and teams that can operate a model as a service. Article 4 of the AI Act requires providers and deployers to take measures to support AI literacy among the staff who operate and use AI systems (1, European Union, 2024). That duty has applied since 2 February 2025 to every AI system, and the 2026 Digital Omnibus on AI softened its original wording, which demanded a sufficient level of literacy, without removing it (27, European Union, 2026). Readiness therefore includes a measurable literacy programme as well as the specialist roles of Chapter 14.
Forsgren, Humble and Kim (2018) showed that capabilities such as version control, continuous integration and automated testing predict delivery performance (70, Forsgren et al., 2018); they are the floor for AI, so engineering practice is a more honest skills indicator than certifications.
Cultural readiness
Culture determines whether the other dimensions improve or stagnate. Westrum (2004) distinguished pathological, bureaucratic and generative cultures by how they handle information: in a pathological culture messengers are shot and failure is punished, whereas in a generative culture messengers are trained and failure leads to inquiry (58, Westrum, 2004), and Forsgren, Humble and Kim found that generative culture predicts both delivery and organisational performance (70, Forsgren et al., 2018). The relevance to AI is direct, because model failures, drift and bias are discovered by people who notice a wrong output and feel safe to say so. In a pathological or bureaucratic culture those signals are lost, and the organisation learns of its failures from a regulator or a newspaper.
Public-sector specifics
Public authorities face every dimension above and three more, each of which can stop a programme outright.
Legal mandate
A public authority may act only within its legal mandate, and processing personal data for a public task requires a basis in Union or Member State law under Article 6(1)(e) and 6(3) of the GDPR (2, European Union, 2016). Using AI in administrative decisions often requires confirmation that the governing legislation permits the processing, and sometimes that it permits automated decision-making at all. The readiness question is whether the legal function has confirmed the mandate in writing before the architecture is designed around it.
Worked example: a legal mandate confirmation
Illustrative example. Nordvik Region records each confirmation as a short note in the use case's repository, and the intake form stays at legalMandateConfirmed: pending until it is merged. Note LM-2026-009 of 2026-09-22 confirms UC-2026-017 with conditions: summarising documents in the case file falls within the public task under GDPR Article 6(1)(e) and 6(3) and the regional social assistance act; medical certificates may be processed under Article 9(2)(g); and Article 22 is not engaged while a caseworker decides. Its conditions, that no correspondence may train a model without a new note and that the note lapses if the purpose changes, become a prohibited purpose in the archive's data contract and a review trigger in the system's declaration, so the platform enforces the legal reasoning. The note illustrates a form; it does not interpret any real statute.
Procurement and transparency
Public bodies acquire AI under Directive 2014/24/EU, whose procedures, thresholds and principles of equal treatment and transparency shape how a system can be specified and bought (9, European Union, 2014). An authority without model clauses for data use and audit rights, or a way to evaluate a supplier's AI Act documentation, is not ready to buy (Chapter 7).
Under the AI Act, a deployer that is a body governed by public law must complete a fundamental rights impact assessment under Article 27 before deploying a high-risk system listed in Annex III (critical infrastructure excepted), and a public-authority deployer must register that use under Article 49(3), and under Article 26(7) an employer must inform workers' representatives before putting a high-risk system into service at the workplace (1, European Union, 2024). Several administrations, the Netherlands among them (23, Dutch Ministry of the Interior, n.d.), also publish algorithm registers, so the authority must be able to describe each system publicly and consult staff and unions.
The readiness scorecard as code
A readiness assessment in a slide deck is forgotten within a quarter; one in a repository can be re-scored, diffed and used as a gate by the deployment pipelines.
# readiness/scorecard.yaml - re-scored quarterly, reviewed by the architecture board
apiVersion: ai-architecture.example.org/v1
kind: ReadinessScorecard
metadata:
organisation: regional-health-authority
assessedOn: 2026-03-31
scale:
description: 0 absent, 1 ad hoc, 2 defined, 3 operating, 4 measured
minimumToIndustrialise: 2
dimensions:
data:
score: 2
evidence: [Data owners named for 14 of 19 clinical data products]
gaps: [No documented lawful basis for secondary use of imaging data]
platform:
score: 3
evidence: [Workload identity and central observability in place]
governance:
score: 1
gaps: [No AI inventory, DPIA template does not cover model training]
skills:
score: 2
gaps: [AI literacy programme covers 30 per cent of staff]
culture:
score: 3
evidence: [Blameless incident reviews in use across IT]
publicSector:
score: 1
gaps: [Legal mandate for automated support in triage not confirmed]
decision:
outcome: remediate-before-scaling
blockingDimensions: [governance, publicSector]
nextReview: 2026-06-30
Three practices make the scorecard useful. First, score with evidence, not opinion: every score above zero cites something that can be inspected. Second, treat the minimum as a gate rather than a target, so that a blocking dimension stops funding or promotion past pilot, enforced by the pipeline. Third, re-score on a fixed cadence and keep the history, because the sequence of scorecards is the organisation's readiness trajectory. Appendix B extends the dimensions into a maturity model.
Worked example: a use-case readiness checklist with scores
Illustrative example. Each use case also needs a narrower check before it leaves pilot. Hansa Mutual completes this one for its claims assistant after a twelve-week pilot.
| Item | Score | Evidence | Gap and owner |
|---|---|---|---|
| Data owner named for every source | 4 | Owners in two data product descriptors | None |
| Source data has a contract with freshness tests | 2 | Contract for policy wordings; guidance has none | Claims Knowledge team, by 2026-07-31 |
| Evaluation set owned, versioned and above thresholds | 3 | eval/claims-assistant/v6: faithfulness 0.96 | Add 50 abstention cases, by 2026-08-15 |
| Oversight and fallback exercised | 2 | Search-only fallback tested once in staging | Exercise in production, by 2026-07-15 |
| ICT third-party register updated (DORA) | 1 | Provider listed; exit plan not written | Exit plan, ICT Risk, by 2026-07-31 |
| Cost per answer within budget | 4 | EUR 0.031 against EUR 0.04 budget | None |
Decision: limited production for two claims centres, with full roll-out blocked until the DORA item reaches 2. The blocking item is not technical, which is typical: the exit plan that Chapter V of DORA expects for an ICT third-party provider supporting an important function is the item pilots most often leave behind (3, European Union, 2022).
Across the usage modes
Readiness depends on how the organisation intends to use language models (usage-mode matrix).
| Mode | Readiness that matters most | Typical blocking gap |
|---|---|---|
| Mode 0 – Ambient AI | AI literacy; procurement change control | No register of AI features that suppliers have switched on |
| Mode 1 – Conversational assistants | Literacy; an acceptable-use statement; an approved tool | Staff using consumer tiers with work data |
| Mode 2 – Embedded workplace assistants | Permission hygiene and sensitivity labelling | Over-shared sites and mailboxes that the assistant can read |
| Mode 3 – Agentic work tools | Engineering practice, repository protection, secrets management | Secrets in repositories; no branch protection |
| Mode 4 – Built AI applications | All six dimensions of the scorecard | Data ownership and lawful basis |
| Mode 5 – Autonomous production agents | All six, with governance and platform at the highest level | Approval workflows and kill switches never exercised |
An organisation can be ready for Mode 1 well before it is ready for Mode 4, and treating readiness as a single number hides exactly that difference.
Nordvik Region and Hansa Mutual
Nordvik Region's readiness turns on the public-sector specifics: intake forms, written mandate notes such as LM-2026-009, and procurement law setting the pace of platform acquisition (9, European Union, 2014). Its weakest dimensions are skills and platform.
Hansa Mutual, by contrast, has a group platform and engineering skills, and its gaps differ by market. A use case ready in Germany may not be ready in Sweden until consumer information exists in Swedish, or in the Netherlands until the works council has been consulted, and the German entity itself needs co-determination before introducing tools that can monitor employees (130, Germany, 2001). The UK and Swiss entities need their own data protection assessments, and transfers to them rely on the Commission's adequacy decisions (189, European Commission, 2025), (191, European Commission, 2000). Hansa therefore adds market-specific items to the group checklist before each national rollout, so that one green score cannot hide a market that is not ready.
Summary
Readiness for enterprise AI is a property of the organisation, not of its models: data with owners, lineage and a lawful basis for training; a platform with infrastructure as code, workload identity and observability; governance with a risk appetite, named roles and routine impact assessment; skills that meet the Article 4 literacy duty; and a generative culture. Public authorities add legal mandate, procurement and transparency duties, each of which can halt a programme. None of this argues for delay; the scorecard shows what to fix first. Data is where any platform build-out begins, with data products in the sense of Dehghani's data mesh (79, Dehghani, 2022). One condition, however, lies outside any internal scorecard: dependence on models trained by others under jurisdictions the organisation did not choose, with which Chapter 6 opens Part II.
Sources
- European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
- European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union. (2, European Union, 2016)
- European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union. (3, European Union, 2022)
- European Parliament and Council of the European Union (2014). Directive 2014/24/EU on public procurement. Official Journal of the European Union. (9, European Union, 2014)
- High-Level Expert Group on Artificial Intelligence (2019). Ethics Guidelines for Trustworthy AI. European Commission. (12, AI HLEG, 2019)
- High-Level Expert Group on Artificial Intelligence (2020). Assessment List for Trustworthy Artificial Intelligence (ALTAI) for self-assessment. European Commission. (13, AI HLEG, 2020)
- International Organization for Standardization and International Electrotechnical Commission (2023). ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. ISO. (32, ISO/IEC, 2023)
- Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28. (48, Sculley et al., 2015)
- Paleyes, A., Urma, R.-G. & Lawrence, N. D. (2022). Challenges in Deploying Machine Learning: A Survey of Case Studies. ACM Computing Surveys, 55(6). (55, Paleyes et al., 2022)
- Westrum, R. (2004). A typology of organisational cultures. BMJ Quality & Safety, 13(suppl 2). (58, Westrum, 2004)
- Nordqvist, G. Architecture as Code. Companion volume, published at aac.geon.se. (66, Nordqvist, 2025)
- Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. (70, Forsgren et al., 2018)
- European Parliament and Council of the European Union (2026). Regulation (EU) 2026/1744 (Digital Omnibus on AI). Official Journal of the European Union. (27, European Union, 2026)
- UNESCO (2021). Recommendation on the Ethics of Artificial Intelligence. UNESCO. (29, UNESCO, 2021)
- UNESCO (2023). Readiness Assessment Methodology: A Tool of the Recommendation on the Ethics of Artificial Intelligence. UNESCO. (30, UNESCO, 2023)
- UNESCO. Ethical Impact Assessment: A Tool of the Recommendation on the Ethics of Artificial Intelligence. UNESCO Global AI Ethics and Governance Observatory. (31, UNESCO, n.d.)
- Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG) (Works Constitution Act), as last amended on 19 July 2024. Federal Ministry of Justice, Gesetze im Internet. (130, Germany, 2001)
- European Commission (2025). Commission Implementing Decision (EU) 2025/2574 amending Implementing Decision (EU) 2021/1772 on the adequate protection of personal data by the United Kingdom. Official Journal of the European Union, 23 December 2025. (189, European Commission, 2025)
- European Commission (2000). Commission Decision 2000/518/EC on the adequate protection of personal data provided in Switzerland. Official Journal of the European Communities, L 215, 25 August 2000. (191, European Commission, 2000)
- Dehghani, Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale. Sebastopol, CA: O'Reilly Media. ISBN 978-1-4920-9239-1. (79, Dehghani, 2022)
- Ministry of the Interior and Kingdom Relations, Netherlands (n.d.). The Algorithm Register of the Dutch government. algoritmes.overheid.nl. (23, Dutch Ministry of the Interior, n.d.)