Is a Written AIS Program Enough? Policy-Only vs Runtime Enforcement

What a written AIS program establishes

A written AIS program defines scope, accountability, risk assessment methods, review schedules and vendor expectations. Regulators treat this as a requirement in its own right. The EU AI Act, for example, requires a risk management system for high-risk AI systems to be established, implemented, documented and maintained. Documentation is part of compliance, not a substitute for it.

The limit of a document is that it describes what should happen. It cannot tell an examiner whether a particular prompt was redacted before reaching a model, whether a tool call was blocked, or who approved an exception. Those are facts about execution, and they exist only if something in the execution path observed and decided them.

That is the practical meaning of the phrase 'necessary but not sufficient'. The written program sets the rules. Whether the rules held on a given day, for a given interaction, is a separate question that needs separate evidence.

Policy-only programs compared with runtime enforcement

The two models differ less in what they intend than in what they can show. The comparison below uses the same questions an auditor would ask of each.

• Individual interactions: Policy-only: guidance to users and teams, with no mechanism to act on a single request. Runtime: policy is applied to each request before it completes.
• Tool calls: Policy-only: permitted tools are listed in a standard. Runtime: each call is allowed, blocked, rate limited or escalated based on policy.
• Human oversight: Policy-only: a documented approval process that may run outside the system. Runtime: escalation for human approval is a step in the path, and the decision is recorded.
• Evidence type: Policy-only: attestations, meeting records and sampled reviews. Runtime: a record for each enforcement decision.
• Coverage: Policy-only: whatever the sample happened to include. Runtime: every interaction that passes through the enforcement point.
• What an auditor can verify: Policy-only: that a policy exists and was reviewed. Runtime: that the policy was applied, and what the outcome was.

Where the gap between policy and operation appears

The gap is usually invisible until someone asks for evidence. Policy-only programs depend on periodic reviews and after-the-fact sampling. A sample can show that a control worked in the interactions examined. It cannot show that the unexamined interactions were handled the same way, and it cannot change the outcome of an interaction that has already finished.

Regulatory language points toward operation, not just design. The EU AI Act requires high-risk AI systems to be designed so that natural persons can effectively oversee them while in use. NYDFS Insurance Circular Letter No. 7 (final, July 11, 2024) says an insurer must have an internal audit function to evaluate control effectiveness and efficiency and compliance with policies and regulations, and that auditing should assess the overall effectiveness of the AIS risk management framework. Evaluating effectiveness is different from confirming that a policy exists.

There is also a trend toward evidence that can be retrieved by technical means. Under the EU AI Act, market surveillance authorities are to be given full access to documentation and to training, validation and testing data sets for high-risk systems, and access may be through APIs or other technical means enabling remote access. This applies to providers of high-risk systems, but it indicates the direction: evidence that is structured and retrievable is easier to produce than evidence assembled from meeting notes.

Timing also matters. As of October 2026, EU AI Act enforcement powers of the AI Office and national competent authorities apply from 2 August 2026 for certain provisions, with other provisions following as they become applicable. Where a non-compliant system is found, the authority must require corrective action, withdrawal or recall within a deadline it sets, and in any event within the shorter of 15 working days or the period in the relevant Union harmonisation legislation. A team that cannot show what its system did will find a short deadline difficult.

Implementation decisions for compliance leaders

Start by mapping each element of the written program to the evidence that would support it. For each element, ask whether the current evidence is a policy attestation, a periodic review or a per-execution record. Elements such as access restrictions on tools, handling of sensitive data in prompts and human approval of exceptions tend to be weak when supported only by attestation, because they describe actions that happen on individual requests.

Keep the documentary elements in place. Vendor and third-party terms still belong in the program, and the final NYDFS letter includes a clause drawn from the NAIC Model Bulletin expecting insurers to incorporate certain terms into third-party vendor contracts where appropriate. Testing should also be documented. The EU AI Act expects high-risk systems to be tested against prior defined metrics and probabilistic thresholds appropriate to the intended purpose, so those thresholds should be written down and revisited.

Align AI risk work with the cybersecurity program. The NYDFS industry letter states that the Cybersecurity Regulation requires Covered Entities to maintain cybersecurity programs, policies and procedures based on risk assessments, and that those assessments must account for AI-related threats, including deepfakes. Finally, plan for change. EU AI Act enforcement is phased by provision, and NIST describes the AI RMF as a living document. Controls that are enforced through configurable policy are easier to update than controls that depend on retraining people and rewriting procedures.

The tradeoff is real. Runtime enforcement adds a dependency in the path of AI traffic, so latency, availability and failure behavior need to be evaluated like any other production control. In return, policy is applied to the interaction itself and the evidence exists when asked for.

Where Trussed fits

Trussed is runtime control for regulated enterprises that must show a regulator or auditor what their AI was allowed to do and what it did. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions to allow, redact, block, rate limit or escalate for human approval on individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact.

That enforcement generates continuous, audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. In production it has run continuously for 18+ months in a regulated enterprise at 99.95% uptime on live traffic, with 100+ models under one policy plane and 30+ GB of audit evidence generated per day. Customers span insurance, pharma, healthcare and education.

Trussed does not replace the written program. It gives the program an enforcement point and a source of per-interaction evidence.