Enterprises are rapidly putting AI to work. Employees use large language models and copilots to work with contracts, customer records, source code and other sensitive information. AI agents are beginning to act on the company’s behalf, accessing systems, generating content and completing work at machine speed. Risk, compliance and security teams already own the policies governing much of this activity. What they have lacked is a way to enforce those policies at machine speed, in the moment a prompt reaches a model.
That creates a fundamental gap between having an AI policy and actually enforcing it. Archer Evolv™ AI Compliance is designed to close that gap by turning the regulations and policies that govern an enterprise into policy as code: approved Amazon Bedrock Guardrails, deployed natively inside the customer’s own AWS account and enforced before a model responds. Every control traces back to the obligation that required it, and every violation is recorded in the GRC system of record enterprises already trust.
The right permissions don’t guarantee the right action
Much of the AI governance conversation has focused on identity, access and zero trust. Those capabilities are essential, but they answer a different question than compliance does. IAM (Identity and Access Management) governs identity. Runtime guardrails govern intent. An employee or AI agent can be correctly scoped, authenticated and logged and still submit a prompt that violates a regulation or company policy that has never been translated into an enforceable control.
An AI agent, in other words, can have exactly the right permissions and still do exactly the wrong thing. Permission tells an organization who can act; compliance determines whether a specific action is allowed under the regulations and policies governing it. As AI systems operate faster and with greater autonomy, enterprises need both.
Traditional compliance programs were designed largely around people and periodic processes: policies, training, attestations, testing and reviews. Those approaches remain important, but they were not designed to inspect every prompt before it reaches a model or review every action an AI agent takes. A policy can be well written and still enforce nothing if it is not connected to the decision or action it is intended to govern.
For AI, compliance therefore has to move closer to the point of action. That means translating the obligations an organization already has into controls that can be enforced at runtime. The challenge is not simply creating a guardrail. It is knowing what that guardrail should enforce, which regulation or policy requires it, who approved it and whether it continues to work as intended as the underlying requirements change.
Prevent the violation, then prove it was prevented
Stopping a violation and proving why it was stopped are two different problems. AI observability tools can detect and report risk, while guardrails can block activity. The harder governance problem is connecting that runtime enforcement back to the regulation or company policy that required the control in the first place. That is where prevention and evidence need to work as one continuous chain.
Archer Evolv AI Compliance brings those pieces together through a five-stage enforcement loop.
- Listen turns regulations, privacy sources and a company’s own policies into tracked controls, drawing on Archer’s 22 million regulatory documents and regulatory expertise.
- Decide turns enforceable controls into draft Amazon Bedrock Guardrails that are deployed only after a named owner approves them.
- Act checks applicable prompts from employees or AI agents before inference, blocking and logging violations.
- Assure tests guardrails on a set cycle against the approved control so risk can be continuously assessed and drift or tampering flagged.
- Learn routes findings into Archer issue management, where they are tracked to closure on the same system of record.
Together, those stages create a connected chain from source to obligation to control to guardrail to violation event and evidence. Instead of simply demonstrating that an AI policy exists, an organization can show the obligation behind the policy, the control designed to enforce it, the guardrail applying that control and the evidence of what happened. That is what turns “we have a policy” into “we can show you the control.”
Figure 1: The five-stage enforcement loop behind Archer Evolv™ AI Compliance
What needs to be governed?
Not every AI obligation comes from a regulation. Organizations also establish their own requirements governing information security, acceptable AI use, confidential information and business risk. Effective AI compliance therefore has to account for both external regulatory obligations and the internal policies an organization expects its employees and AI agents to follow.
Organizational obligations can include credentials and secrets such as API keys and tokens, source code and proprietary technical assets, confidential business information such as contracts, pricing and M&A activity, and company-defined rules governing what a model may address, do or combine. Regulatory obligations can include personal data governed by GDPR, CCPA and state privacy laws; protected health information under HIPAA; payment and cardholder data under PCI DSS; and regulated categories such as export-controlled data, securities information and biometric data.
The important distinction is that the guardrail is not simply looking for generic unsafe content. It is connected to the specific regulation or policy behind the control. That connection gives risk, compliance and security teams a way to understand not only that an AI interaction was blocked, but why it was blocked and which obligation required the control.
Keep enforcement where the AI runs
For models running in Amazon Bedrock, Archer Evolv AI Compliance uses native Amazon Bedrock Guardrails inside the customer’s own AWS account. No Archer proxy sits in the inference path. Archer connects through a scoped, least-privilege AWS IAM role and reads guardrail configuration and events, not customer AI traffic. Prompt content, model responses, documents, embeddings, PII, model weights and training data do not reach Archer. If connectivity to Archer is interrupted, the native Amazon Bedrock Guardrails continue enforcing as last deployed.
Models outside Amazon Bedrock can apply the same approved control through the Amazon Bedrock Apply Guardrail API, extending the policy and evidence chain beyond models running directly in Amazon Bedrock. This approach keeps enforcement close to where AI runs while Archer maintains the governance, regulatory lineage and evidence surrounding the control.
Customers also remain in control of how enforcement is introduced.
- Observe, Archer logs what a guardrail would block.
- Advise routes a finding and supporting evidence to a named owner.
- Enforce blocks violations before inference. Nothing moves up that enforcement dial without approval, and versions can be rolled back.
This balance matters. The guardrail performs work a person cannot reasonably do at machine speed by evaluating applicable prompts against controls before the model responds. People remain accountable for the decisions they should own: approving controls, managing exceptions and determining when enforcement should change. Runtime enforcement does not remove people from compliance; it gives them a way to apply the policies they already own at the speed AI now requires.
From AI policy to AI proof
The harder problem in AI governance is increasingly not writing another policy. It is translating that policy into controls that operate at the same speed as AI and maintaining the evidence needed to demonstrate that those controls are working.
Archer brings a distinctive advantage to that problem. Its proprietary regulatory intelligence draws on 22 million regulatory documents and 492 purpose-built models trained since 2017. That intelligence helps connect the regulation or company policy to the control, the control to the guardrail, and the guardrail to the evidence. Instead of requiring enterprises to build that chain themselves, Archer brings together the regulatory context, control framework, runtime enforcement and GRC system of record.
For risk, compliance and security leaders, that changes the question they should be asking about AI. It is no longer enough to ask whether the organization has an AI policy. The more important question is whether, if an employee or AI agent violated that policy today, the organization could show what happened, which control applied and why.
If answering that question requires a manual investigation, there is still a gap. Archer Evolv™ AI Compliance is designed to close it by moving compliance from policy on paper to controls that can be enforced, monitored and proven at machine speed.
Learn more about Archer Evolv AI Compliance: https://www.archerirm.com/archer-ai-compliance
Read the full announcement on Archer Evolv AI Compliance: https://www.archerirm.com/press-releases/archer-launches-archer-evolv-ai-compliance
FAQs
Archer Evolv™ AI Compliance turns an enterprise’s regulations and policies into policy as code: approved Amazon Bedrock Guardrails, deployed natively inside the customer’s own AWS account, enforced before a model responds. Every control traces back to the obligation that required it, and every violation is recorded in the GRC system of record.
No. IAM (Identity and Access Management) governs identity; runtime guardrails govern intent. An employee or AI agent can be correctly scoped, authenticated and logged and still submit a prompt that violates a regulation or policy that was never translated into an enforceable control. Permission determines who can act. Compliance determines whether a specific action is allowed. AI systems need both.
1. Listen turns regulations, privacy sources and company policies into tracked controls, drawing on Archer’s 22 million regulatory documents and regulatory expertise.
2. Decide turns those controls into draft Amazon Bedrock Guardrails, deployed only after a named owner approves them.
3. Act checks applicable prompts before inference, blocking and logging violations.
4. Assure tests guardrails on a set cycle against the approved control to flag drift or tampering.
5. Learn routes findings into Archer issue management, tracked to closure on the same system of record.
Both organizational and regulatory obligations. Organizational obligations include credentials and secrets such as API keys and tokens, source code and proprietary technical assets, confidential business information such as contracts, pricing and M&A activity, and company-defined rules governing what a model may address, do or combine. Regulatory obligations include personal data under GDPR, CCPA and state privacy laws, protected health information under HIPAA, payment and cardholder data under PCI DSS, and regulated categories such as export-controlled data, securities information and biometric data.
No. For models running in Amazon Bedrock, enforcement runs on native Amazon Bedrock Guardrails inside the customer’s own AWS account. Archer connects through a scoped, least-privilege AWS IAM role and reads guardrail configuration and events, not customer AI traffic. Prompt content, model responses, documents, embeddings, PII, model weights and training data do not reach Archer. If connectivity to Archer is interrupted, the native guardrails keep enforcing as last deployed.
Models outside Amazon Bedrock can apply the same approved control through the Amazon Bedrock Apply Guardrail API, extending the policy and evidence chain beyond models running directly in Amazon Bedrock.
Through three settings. Observe logs what a guardrail would block. Advise routes a finding and supporting evidence to a named owner. Enforce blocks violations before inference. Nothing moves up that dial without approval, and versions can be rolled back.
No. The guardrail does work a person can’t reasonably do at machine speed: evaluating applicable prompts against controls before the model responds. People still own approving controls, managing exceptions and deciding when enforcement should change.
The full chain from source to obligation to control to guardrail to violation event to evidence: not just that a policy exists, but the obligation behind it, the control designed to enforce it, the guardrail applying that control and the evidence of what happened when it was tested.
Archer’s regulatory intelligence draws on 22 million regulatory documents and 492 purpose-built models trained since 2017, connecting the regulation or policy to the control, the control to the guardrail and the guardrail to the evidence, rather than requiring enterprises to build that chain themselves.
