Archer Turned Compliance Policy Into Runtime Guardrails — Stop Governing AI With a PDF

Archer Turned Compliance Policy Into Runtime Guardrails — Stop Governing AI With a PDF

2026-10-05

Risk and compliance teams already write the rules for what may enter a model. For most companies, those rules still live in documents. Archer, the governance, risk, and compliance (GRC) software provider, now sells a product that turns them into runtime controls: Amazon Bedrock Guardrails that block non-compliant prompts before a model can answer, with every block traced back to the regulation or policy that required it (Archer). It launched in mid-September and is drawing fresh coverage this week as enterprises figure out how to govern employees and agents at the same time (FinTech Global).

The takeaway for owners and operators is blunt: if your AI policy still stops at a PDF and an acceptable-use slide, you are governing access while ignoring intent.

What Archer shipped

Archer Evolv AI Compliance maps regulations and company policies into approved Bedrock Guardrails, deployed inside the customer’s own AWS account. Every prompt from an employee or an agent is checked ahead of inference. Violations are blocked and logged into the GRC system of record the company already uses (Archer; FinTech Global).

Archer’s Chief Product and Technology Officer Kayvan Alikhani put the design principle plainly: “A guardrail is only as good as the obligation behind it.” Someone has to capture the regulation, map it to a control, and keep that mapping current. Archer’s pitch is that it already does that work with legal experts in the loop, drawing on a library of about 22 million regulatory documents and hundreds of purpose-built models trained since 2017 (Archer).

The product rolls out in three modes: Observe (log what would have been blocked), Advise (send evidence to a named owner), and Enforce (block before inference). Moving between modes needs approval, and every version can be rolled back. If Archer’s connection drops, the native Bedrock guardrails keep enforcing in their last deployed state (FinTech Global).

Why “who can use ChatGPT” is the wrong half of the problem

Most AI governance this year has focused on identity and access: who may reach which model. That is necessary. It is also incomplete.

An authenticated employee can still paste an API key, a customer contract, or a HIPAA-covered record into a prompt. An authenticated agent can do the same thing a thousand times before lunch. Permission says who may act. A runtime guardrail says whether that specific action is allowed.

Archer frames the gap cleanly: IAM governs identity; runtime guardrails govern intent (Archer). That distinction matters once your company runs two AI workforces at once: people with copilots, and agents acting on the company’s behalf at machine speed.

What the guardrails actually cover

Archer splits obligations into two buckets.

Organizational obligations cover credentials and secrets (API keys and tokens get special attention, because a leaked secret turns a data-loss event into an access event), source code, confidential business information like pricing and M&A material, and custom usage rules.

Regulatory obligations cover personal data under GDPR, CCPA, and US state privacy law, health information under HIPAA, cardholder data under PCI DSS, plus export-controlled, securities, and biometric categories (Archer).

Importantly, Archer says it does not sit as a proxy in the inference path. It connects through a scoped AWS IAM role and reads guardrail configuration and event data. Prompts, outputs, documents, embeddings, and model weights stay in the customer’s environment. Models outside Bedrock can still apply the same controls via the Amazon Bedrock Apply Guardrail API (FinTech Global).

A practical “policy as runtime” checklist

You do not have to buy Archer to steal the operating model. You do have to stop treating AI compliance as a training video.

  1. Inventory the prompts that already matter. Where do staff paste contracts, customer data, source code, or credentials today? Where do agents call models on your behalf? If you cannot name those paths, you cannot put a control on them.
  2. Translate three policies into enforceable rules this month. Pick the ones that hurt most if they fail: secrets in prompts, regulated personal data leaving the boundary, and “do not use this model for legal advice” style usage rules. Write them as block-or-allow controls, not as vibes.
  3. Start in Observe, then move to Enforce with a named owner. Shadow mode without a promotion path is theater. Every promotion, edit, and rollback should have a human name on it, the same way you treat a firewall change.
  4. Connect blocks to your existing issue system. A blocked prompt that dies in a log nobody reads is not compliance. Route findings into the same issue management process your auditors already understand.
  5. Cover agents and humans with the same dial. If people get Observe-and-train and agents get full Enforce, you have already admitted which workforce is riskier. Design for both, or the agent path will invent itself around the policy.
  6. Separate GenAI data security from model shopping. Picking a model is a capability decision. Keeping secrets and regulated data out of every model is a control decision. Do not let the first delay the second.

Build vs buy without the theater

Some teams will wire Amazon Bedrock Guardrails by hand. That works if you have the staff to map obligations and keep them current. Archer’s bet is that most companies do not, and that the hard part is the living map from regulation to control, not the blocklist.

Either path beats the common default: an AI usage policy in the handbook and a hope that people read it.

Soft next step

Yellow Coop helps owners and operators turn AI policy into something their stack can enforce: GenAI data security, continuous compliance for agents and copilots, and the fractional CTO judgment to decide what must be blocked before a model ever answers. If your AI rules still live in a PDF, we can help you turn them into runtime controls. See our track record, or start at contact.

Internal links: Secure, What We Do, How We Engage, CIO vs CTO vs CISO, Track Record, Insights.

Sources