A heavy steel gate spanning a dark server-room corridor, rimmed in electric-blue light with a small glowing control panel beside it - a metaphor for an enforcement point every agent action must pass through before it can proceed

Most conversations about AI governance stop at a document. A policy gets written, a committee signs off, a model card gets filled in, and everyone agrees the system is "governed." Then the agent goes into production, starts calling tools, sending messages, and making decisions on its own, and the document sits in a wiki where it cannot reach a single one of those actions.

There is a gap between governance that describes what should happen and governance that controls what does happen. For teams building agentic workflows in regulated industries, that gap is where the risk lives. This piece is about how to close it, using a debt-collection example that turns out to be a good stress test for the whole problem.


The idea that looks easy and isn't

Start with a request we hear often. A collections team wants to know who is likely to pay and how best to reach them. The raw material seems abundant and free: Census and Bureau of Labor Statistics data, public records, all of it sitting there waiting to be turned into scores that feed a model. Enrich an address, attach a few socioeconomic features, drop the result into the propensity model that is already consuming credit scores. It sounds like a weekend of feature engineering.

It is not, and the reasons it is not are the reasons governance has to be more than a document.


Bias is not a field you can delete

The first wrong turn is the most natural one. A careful team says: we will not use race, or any protected attribute, so we cannot be accused of discrimination. This feels responsible. It does almost nothing.

Bias in data is not a column. It is a property of the relationships in the data. When you remove a protected attribute, every variable that correlates with it stays behind and continues to carry its signal. The technical term is proxy encoding, and in consumer data it is everywhere.

Proxy encoding

Geography is the clearest case. Area-level income, home values, and housing data track the racial composition of neighborhoods closely, because decades of redlining and residential segregation built that correlation into the map itself. A model that never sees a person's race can reconstruct a usable estimate of it from their ZIP code. The disparate impact arrives just the same, through the side door.

The second wrong turn compounds the first. The intuition that more data improves a model pushes teams to stack on additional socioeconomic and behavioral layers. But each correlated layer you add is another route to the same protected characteristic. You can strengthen the proxy while believing you are enriching the model, and you take on accuracy, provenance, and dispute obligations for every new field at the same time. More inputs widen the exposure rather than narrowing it.

The third point is the one that ties the knot. Disparate impact law does not ask whether you used a forbidden variable. It asks whether a facially neutral practice produces a discriminatory effect.[1] The test is about outcomes, not intent and not inputs. So a feature set that looks clean on inspection can still fail, and "we did not use race" is precisely the defense that regulators and plaintiffs expect to hear and are well practiced at taking apart.

This reframes fairness in a way that matters for everything that follows. Fairness is not something you achieve by leaving fields out. It is a property of outcomes that you have to measure and be able to demonstrate. That means estimating effects across protected groups, often through statistical proxy methods, running real disparity analysis, searching for less discriminatory alternatives that serve the same business purpose, and documenting the business necessity of whatever disparity remains. It is affirmative work, it is partly statistical and partly legal judgment, and no tool makes it disappear. What a tool can do is enforce the result of that work on every decision and keep the evidence. Hold that thought.


The regulatory web is denser than one law

Suppose you navigate the bias problem honestly. The next surprise is how many regimes a household-level scoring product touches at once.

FCRA

It is about use, not source

The Fair Credit Reporting Act turns on what the information is and what it is used for, not where it came from. Aggregating public records into a score about a person, sold for decisions about that person, can make you a consumer reporting agency - no matter that the raw data was free.

FDCPA / Reg F

Limits on every contact

Debt collection is governed by the FDCPA and the CFPB's Regulation F, which set concrete limits on how and when a collector may contact a consumer - including the seven-calls-in-seven-days presumption and cross-channel opt-out.

Disparate impact

Judged on outcomes

Fair-lending law asks whether a neutral practice produces a discriminatory effect. A clean-looking input set can still fail the test, which is why fairness has to be measured and demonstrated, not asserted.

The Fair Credit Reporting Act is the one most teams underestimate, and the way they underestimate it is instructive. The FCRA does not care that your inputs came from free public sources. It turns on what the information is and what it is used for. The statute defines a consumer reporting agency broadly, to include anyone who regularly assembles or evaluates information about consumers for the purpose of furnishing reports used in decisions about credit, insurance, employment, housing, and similar eligibility determinations.[2] Aggregating public records into a score about a person, sold for use in decisions about that person, can land you inside that definition no matter where the raw data started.

This is not a theoretical reading. The Federal Trade Commission has taken the position for years that data brokers who assemble and sell consumer information are consumer reporting agencies subject to the FCRA, and it has run an active enforcement program built on exactly that theory, including a test-shopping operation in which staff posed as buyers seeking consumer information for creditworthiness and eligibility decisions, then sent warning letters to companies that offered the data without meeting FCRA obligations.[3] The CFPB has since moved to codify this view, proposing rules that would make explicit when information sold by data brokers meets the definition of a consumer report.[4]

The FCRA's four pillars

If you become a consumer reporting agency, the obligations are ongoing, not a one-time checklist: a prohibition on furnishing reports except for permissible purposes; a requirement to follow reasonable procedures to assure maximum possible accuracy; a consumer right to dispute and correct information; and a consumer right to see their own file.[5] Each is a duty attached to every report you furnish.

Now add the collections context, and a second body of law switches on. Debt collection is governed by the Fair Debt Collection Practices Act and, since 2021, by the CFPB's Regulation F, which sets concrete limits on how and when collectors may contact consumers. The most discussed provision is the call frequency rule: a collector is presumed to violate the law if it places more than seven telephone calls to a person about a particular debt within seven consecutive days, or calls within seven days after a telephone conversation about that debt.[6] The seven days roll continuously rather than resetting with the calendar week, and every attempt counts whether or not anyone answers.[7] Regulation F also requires a reasonable and simple way for consumers to opt out of contact through a given channel, and the CFPB has said it will look at the cumulative effect of all communication methods to judge whether conduct amounts to harassment.[8]

Read the rule like an engineer

To know whether the next call is allowed, you have to know how many calls went to this specific person about this specific debt in a rolling window, whether a conversation happened in the last seven days, what time it is where the consumer lives, and whether they have opted out on this or any other channel. Compliance here is not a statement of policy. It is a decision that has to be made correctly, in context, on every single action, before the action happens.


Why a policy document cannot reach the action

This is the moment where the usual model of governance breaks.

The standard approach is what we will call passive governance. A policy is attached to an asset, an artifact is collected, evidence is filed. You document that a model was tested for correlation bias. You write down your Regulation F procedures. This has real value for the record, but notice what it does not do: it does not sit between the agent and the world. It observes and it documents. It does not prevent.

Passive

Governance that describes

A policy attached to an asset; evidence filed after the fact. It observes and documents. It sits in a wiki, not in the path. It cannot prevent a single action, and it cannot answer "was this specific call allowed?" for ten thousand calls a day.

Active

Governance that controls

The action is intercepted at the moment the agent tries to take it and evaluated against the rules before it can execute. Allow, block, or hold - and every decision recorded. Enforcement, in the path, with proof.

For autonomous systems, that is no longer enough, and the reason is specific to how these systems fail. An AI agent that can place a call, send a text, or send an email decides for itself, in the moment, whether to act. You cannot govern that decision with a policy written in a document, and you cannot govern it by writing instructions into a prompt either. Prompt-level safety is a request, not a control. The published research on adversarial attacks against language models is blunt on this point, with adaptive attacks reaching near-total success rates against frontier safety-aligned models.[9] A rule that lives only in a prompt is a rule the system can be argued out of.

Was this specific action allowed? Which agent took it? Can you prove, after the fact, what rule was in force and why the action was permitted or denied? A document cannot answer those questions for ten thousand calls a day. Something has to be in the path.

So the question for anyone deploying agents in this environment is no longer "do we have a policy." It is the question an examiner or a plaintiff's lawyer will actually ask. Was this specific action allowed? Which agent took it? Can you prove, after the fact, what rule was in force and why the action was permitted or denied?


Active governance: enforcement where the action happens

Active governance is the difference between describing the rules and enforcing them. Instead of attaching a policy to an asset and collecting evidence later, you intercept the action itself, at the moment the agent tries to take it, and you evaluate it against the rules before it can execute.

Active Governance
Every gated action passes through the enforcement point
Evaluate the live state, return allow / block / hold, and record the decision - before the action executes.
AGENT ACTION call - SMS - email batch + streaming gate DECISION ENGINE attested policy in force contact history (rolling 7d) local time - opt-out, all channels deterministic - fails closed ALLOW action proceeds BLOCK never executes HOLD human review TAMPER-EVIDENT LOG request - policy version - decision - why

In practice this means every gated action, every phone call, SMS, and email the agent tries to send, passes through an enforcement point on its way out. That point asks a decision engine a single question: is this specific action, for this specific consumer, in this specific context, allowed right now? The engine evaluates the active policy against the live state that the rules actually require: the contact history in the rolling window, the consumer's local time, their opt-out status across all channels. It returns one of three answers.

Allow

The action proceeds and executes.

Block

The action never happens. It is stopped before it leaves the system.

Hold

The action is suspended for a human to review.

Two design choices make this trustworthy rather than just clever. The engine fails closed: if it cannot reach the state it needs, cannot evaluate a case, or meets a situation the policy does not cover, it holds or blocks. It never defaults to letting the action through. And it is deterministic: it enforces the rules a qualified person has already attested to, rather than improvising a legal judgment in the moment. The human owns the policy. The machine applies it consistently and records what it did.

That recording is not a byproduct. Every decision is written to a tamper-evident log that captures what was requested, which version of the policy was in force, and why the action was allowed, blocked, or held. When an examiner asks why a particular contact went out last March, you point to the exact attested ruleset that was active and the decision it produced. The audit trail that compliance teams normally assemble under deadline pressure becomes something the system produces automatically, as it runs.

Where the fairness thread lands

You cannot prove an outcome property like fairness with a policy document. You prove it by testing, and then by enforcing the tested, attested result on every action and keeping the evidence. Active governance is what turns the hard, human work of fairness analysis and regulatory interpretation into something that actually holds at runtime, on every decision, at scale.


How Strongly does this

Strongly is an enterprise platform for getting AI into production, and active governance is built into how agents and workflows run on it, not bolted on afterward.

Part of what makes that possible is that the outbound channels run on Strongly too. Agentic workflows on the platform can place phone calls, including with streaming voice agents, send SMS, and send email as native actions, across both batch runs and real-time streaming. This matters for more than convenience. When the channel that performs the contact and the layer that governs it are the same platform, enforcement is not a system watching from the outside and hoping to catch a violation after the message has gone out. It is in the path, because the path runs through Strongly. The agent that wants to dial a number and the control that decides whether it may are part of one system, which is exactly the position from which a rule can be enforced rather than merely recorded.

Governance on Strongly is delivered as policy that plugs directly into the platform's enforcement layer and gates these agent actions in both batch and streaming workflows. Your compliance team and counsel author and attest a policy, the platform versions and signs it, and once it is active it sits in the path of every gated action. Non-compliant actions do not get logged after the fact and apologized for. They are structurally prevented from executing. A call that would be the eighth in seven days, a contact outside permitted hours in the consumer's time zone, a message to someone who has opted out: the enforcement layer stops it before it leaves the system.

What the platform does and does not do

Strongly enforces the policy your qualified team attests to. It does not make the legal determination for you, and it does not decide what fair means on your behalf. What it does is make the rules you and your counsel have committed to impossible to violate in execution, apply them identically to every action, and produce the signed, versioned, tamper-evident evidence trail that proves what happened. The hard judgment stays human. The enforcement and the proof are automated.

Because the policies are versioned, attested artifacts that deploy through the marketplace, the same approach extends past any single rule set. Regulation F call gating is one policy. Permissible-purpose checks, state collection statutes, and other regimes are additional policies on the same enforcement spine. You build the control surface once and add coverage as content, not as new engineering.

There is a broader point here for anyone evaluating where to build agentic workflows in the first place. A platform that can reach out to customers by phone, SMS, and email, run those campaigns at batch scale and in real-time streaming, and govern every one of those actions in the same place, collapses a stack that teams usually assemble from a telephony vendor, a messaging vendor, an orchestration layer, and a separate compliance bolt-on that never quite sees the actual traffic. Bringing the channels and the governance under one roof is what makes the enforcement credible, and it happens to make the workflows simpler to build and operate as well.

The teams that will navigate the next few years of AI regulation are not the ones with the best-written policies. They are the ones who can prove, action by action, that their autonomous systems did only what they were allowed to do.

That proof does not come from a document. It comes from governance that lives where the decisions are made, on a platform where the decisions and the actions are one system.