They fail because they cannot reliably prove that the required controls actually ran before production. Manual processes fragment approvals, policy decisions, and evidence across tools, so audit teams must reconstruct the story after the fact. That is too weak for regulated AI delivery, where traceability and accountability need to be built into execution.
Why spreadsheets collapse under EU AI Act readiness demands
Readiness for the EU AI Act is not just about having policies on paper. It is about being able to show that risk classification, approvals, data controls, logging, human oversight, and post-deployment obligations were executed in the right order and with the right evidence. Spreadsheets can track tasks, but they are brittle when the question becomes whether a control was actually enforced, by whom, and against which model, dataset, or release.
The core problem is traceability. Manual reviews tend to separate decision-making from the systems that produce evidence, so the organisation ends up with isolated sign-offs instead of a durable compliance record. That creates gaps when regulators, internal audit, or legal teams ask for end-to-end proof across the model lifecycle. A spreadsheet may show that a review happened, but not that the control was binding, current, and tied to the deployed version. In practice, many security and governance teams discover those gaps only when they are forced to reconstruct the compliance trail after a release has already gone live.
How manual review breaks the control chain in practice
Manual readiness processes usually fail at the points where AI governance becomes operational. A reviewer may approve a risk assessment in one document, a data steward may record a separate exception elsewhere, and the engineering team may deploy a model from yet another system. Once that happens, the organisation no longer has one reliable chain of evidence connecting the policy to the control, the control to the release, and the release to the model instance that actually shipped.
That matters because eu ai act readiness is not only a documentation exercise. It depends on being able to demonstrate consistent execution across the lifecycle, especially where obligations involve classification, transparency, technical documentation, monitoring, and human oversight. Spreadsheets encourage a point-in-time view, but regulatory readiness is cumulative. The system must preserve who approved what, when the approval applied, what changed afterwards, and whether the evidence still matches the deployed artefact.
- Manual reviews often lose version linkage, so the approved record no longer matches the live model.
- Evidence is commonly spread across email, tickets, documents, and shared drives, which makes reconstruction slow and error-prone.
- Exception handling becomes inconsistent because each reviewer may interpret the same control differently.
- Ownership can drift when the people who approved a control are not the same people operating the model later.
Where this breaks down most sharply is at scale, when multiple models, releases, and exceptions move in parallel and the manual process can no longer preserve a dependable audit trail.
Where the spreadsheet answer is too simple
Tighter documentation often increases process overhead, requiring organisations to balance fast delivery against evidential integrity. That trade-off is especially visible in AI programmes that are still evolving, because the governance process can look complete even when it is only loosely connected to the deployed environment.
There is also an important distinction between internal comfort and external defensibility. A spreadsheet can make a programme look orderly, but if the evidence does not survive version changes, delegation, or release churn, it will not support accountability under scrutiny. The same issue appears when teams rely on informal reviewer judgment instead of a repeatable control model. Guidance versus consensus is still emerging on the exact tooling pattern, but there is broad agreement that compliance evidence must be linked to execution rather than assembled afterwards. For background on the regulatory context, the EU AI Act regulatory framework is the relevant reference point.
Manual review also struggles when the organisation must prove negative assertions, such as that a required gate was not bypassed or that a post-change review actually occurred before production. Those are not just administrative details; they are the places where weak governance becomes a compliance failure.
Risk and Threat Considerations
The main risk is evidential fragility. When approvals, exceptions, and release decisions live in disconnected manual artefacts, the organisation may be unable to prove that required safeguards were active before deployment. That creates exposure in audits, regulatory review, and incident response because the compliance story depends on reconstruction rather than live records.
Failure mechanism: manual workflows break the control chain by separating policy, approval, and deployment evidence, which makes version drift, missed reviews, and inconsistent exception handling hard to detect until after release.
Impact: the organisation may be unable to demonstrate accountability for a model already in production, weakening its position with regulators and complicating internal decisions about remediation, rollback, or exception closure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF set the technical controls, while EU AI Act, EU AI Act, EU AI Act and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | Article 9 | The question is about readiness for EU AI Act obligations and control execution. |
| Recommendation: Requires ongoing AI risk controls to be operational, not just documented. | ||
| EU AI Act | Article 11 | Spreadsheet-based readiness fails when documentation cannot prove version-linked control execution. |
| Recommendation: Expects documentation that supports traceable, auditable compliance evidence. | ||
| EU AI Act | Article 12 | Manual reviews fail when evidence is fragmented and cannot reconstruct what happened before production. |
| Recommendation: Requires records that preserve the compliance trail across the AI lifecycle. | ||
| ISO/IEC 42001:2023 | A.6 | The problem is lifecycle governance of AI controls and release evidence. |
| Recommendation: Implies AI governance must remain linked to changes, approvals, and deployment. | ||
| NIST AI RMF | GOV-3 | The question concerns whether governance evidence is reliable enough for regulated AI readiness. |
| Recommendation: Reinforces that AI governance needs durable, reviewable evidence across decisions. | ||
Practitioner Guidance
What to prioritise: Treat evidence continuity as the primary design requirement, not a reporting afterthought. If a control cannot be tied to the exact model version, dataset, approver, and deployment event, it is not readiness evidence in any meaningful sense.
What to verify: Check whether approvals are still valid after a model changes, whether exceptions expire or are re-authorised, and whether the record set can survive a challenge without relying on memory, email threads, or manual reconstruction.
Common mistake: Teams often assume that more review steps equal more readiness. In practice, additional checkpoints that are not bound to execution can increase noise without improving defensibility.
Practitioner takeaway: EU AI Act readiness fails when governance is treated as a document trail instead of a control trail; the test is whether evidence stays attached to the live system as it changes.
