What breaks when AI Act compliance depends on spreadsheets and policy documents?

What breaks is evidentiary control. Spreadsheets can list obligations, but they cannot reliably prove classification, oversight, log retention, or human review when regulators ask for traceable records. Teams that depend on static documents usually discover gaps only during audit preparation, when the cost of reconstruction is highest.

Why This Matters for Security Teams

AI Act compliance fails quickly when evidence is treated as a document exercise instead of a control exercise. A spreadsheet can help track obligations, but it does not prove that a system was classified correctly, that human oversight actually occurred, or that logs were retained in a way regulators can verify. Under the EU AI Act, the issue is not simply whether a policy exists, but whether the organisation can demonstrate operational accountability across the AI lifecycle.

This matters because high-risk AI obligations depend on traceability, repeatability, and evidence retention. Teams often maintain policy statements, risk registers, and approval notes in disconnected files, then assume the package is audit-ready. In practice, that creates a gap between governance intent and control performance. Frameworks such as NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce the need for managed, testable controls rather than informal recordkeeping. In practice, many security teams encounter compliance failure only after audit preparation has already exposed missing evidence, not through intentional control testing.

How It Works in Practice

Spreadsheets and policy documents usually fail in three places: ownership, version control, and evidentiary depth. A spreadsheet may show that an AI system is “approved,” but not who approved it, on what basis, using which model version, with what risk acceptance, and whether ongoing monitoring confirmed that the decision still holds. Policy documents can set expectations, yet they rarely capture the operational artefacts needed to prove control execution.

Effective AI Act compliance needs evidence tied to the lifecycle of the system. That means preserving the classification decision, risk assessment, testing results, human oversight procedure, incident escalation path, and change history for models, prompts, and deployment settings. Where AI is integrated into broader security and governance processes, align this with ISO/IEC 27001:2022 Information Security Management and ISO/IEC 27002:2022 Information Security Controls so evidence is attached to a managed control environment, not an ad hoc folder structure.

• Use a controlled register for AI systems, not a static spreadsheet copied across teams.
• Link each AI system to documented risk classification, review dates, and accountable owners.
• Store approval records, testing outputs, and monitoring results in a system that preserves immutability or audit history.
• Connect policy statements to operational evidence so auditors can trace “what is required” to “what was done.”
• Keep logging and retention requirements specific to the AI use case, not generic enterprise defaults.

This control pattern breaks down in decentralised environments where business units deploy AI tools through shadow procurement, because no single system reliably captures ownership, change history, and review evidence end to end.

Common Variations and Edge Cases

Tighter evidence control often increases administrative overhead, requiring organisations to balance audit readiness against speed and local autonomy. That tradeoff is real, especially where AI is embedded in experimentation workflows or fast-moving product teams. Current guidance suggests that the answer is not more policy text, but a more reliable evidence chain.

There is no universal standard for this yet, but practical implementations usually differ by AI risk level. Low-risk tools may need lighter records and periodic review, while high-risk systems need structured sign-off, traceable testing, and retention aligned to regulatory expectations. The same applies when AI supports compliance-adjacent functions such as fraud, AML, or identity workflows, where FATF Recommendations — AML and KYC Framework expectations can amplify the need for defensible records.

One common edge case is vendor-hosted AI. If the provider controls logging or model updates, the organisation still needs contractual access to evidence, not just a policy that says oversight exists. Another is rapid model iteration, where evidence becomes stale unless the change process is versioned alongside deployment. The practical test is simple: if an auditor asked for proof today, could the team reconstruct the decision path without relying on memory or email threads?

Related resources from NHI Mgmt Group

• What breaks when AI compliance stops at policy documentation?
• What breaks when security teams govern AI agents only through policy documents?
• What breaks when AI assistants are allowed to act on behalf of users without policy checks?
• What breaks when AI governance is limited to policy documents and dashboards?