The Medieval Way to Regulate AI
← Back to Articles

The Medieval Way to Regulate AI

Why banning named AI use cases cannot substitute for runtime authorization, fail-closed governance, and independently reconstructable authorization artifacts. Category bans chase renameable labels. The durable control is a non-bypassable authorization boundary that fails closed and leaves an independently reconstructable artifact.

The Medieval Way to Regulate AI

Why Category Bans Cannot Substitute for Runtime Authorization

Banning a named AI use case may feel decisive. As a regulatory strategy, it is closer to medieval governance than to modern control architecture. It identifies a feared category, prohibits the category, and assumes the risk has been contained.

The pattern is familiar. Mental-health bots. Hiring bots. Lending bots. Legal-advice bots. The list can grow indefinitely, and that is the first sign of the problem. A control that has to enumerate every prohibited thing is a control that can never finish.

The concern behind the impulse is real. Some AI systems acting in consequential domains can cause serious harm, and a regulator who reaches for a prohibition is responding to something genuine. The concern is not the problem. The control strategy is the problem.

The difficulty is not only that category bans are incomplete. In other domains, an incomplete prohibition can sometimes be repaired by articulating the underlying condition more generally. A rule against one distracting act can be reframed as a duty to maintain control. But with high-stakes AI, a sufficiently general prohibition quickly becomes either vague or paralyzing. Ban the named use case and the rule is underinclusive. Define the prohibited condition broadly enough and the rule begins to prohibit the very system it is meant to govern. That is the prohibition dilemma: incomplete if narrow, unsustainable if complete. Authorization avoids the dilemma by asking whether a specific consequential action is permitted before execution.

That question is architectural, not nominal. It does not ask what the system is called. It asks where authority attaches before the system acts.

The label is not the control

Consider how easily the categories dissolve.

  • A therapy bot becomes a wellness companion.
  • A hiring bot becomes a workforce insight assistant.
  • A legal-advice bot becomes a document navigation tool.
  • A lending bot becomes a customer eligibility experience.

None of these renamings changes what the system does. Each changes only the noun under which it does it. A regime built on prohibited nouns is in a vocabulary race it cannot win, because the vocabulary is controlled by the party with the incentive to evade.

The label is not the control. The control is authorization.

Three problems that are routinely conflated

Part of why category bans persist is that AI governance discourse collapses three distinct problems into one word.

The first is operational visibility: knowing what a system did. The second is behavioral alignment: shaping what a system tends to do. The third is decision authorization: determining whether a specific consequential action is permitted before it executes. These are different problems with different solutions, and a measure aimed at one does not discharge the others (FERZ, A Taxonomy of AI Governance Approaches).

Disclosure mandates, logging requirements, and monitoring overlays are mostly instruments of visibility and alignment. Category bans are prohibition instruments attached to labels. None is an instrument of authorization. Treating them as if they were is the central category error in current governance proposals, and it has a formal consequence.

Observability is not authorization

The strongest version of the authorization claim is not rhetorical. It is a structural impossibility result, established in the FERZ corpus, that no observability architecture can produce the authorization artifact an ex-ante regulatory regime requires (FERZ, On the Impossibility of Observability-Based Authorization).

An ex-ante regime requires, before a consequential action executes, an authorization artifact with four properties. It is emitted before execution, not after. It takes a value in a defined verdict space. It is the output of a decision procedure whose inputs are policy, context, and the proposed action specification. And it is reproducible by an independent party holding only those inputs and the artifact, without access to the governed system's internal state.

The impossibility result rests on three observations.

First, observational signals are causally posterior to the action they would authorize. A signal that exists only because the system began generating an action cannot precede that action. Observation of an event cannot come before the event.

Second, a verdict derived from observing the governed system cannot be verified independently of that system. To reconstruct such a verdict, a third party would have to re-run the observation, which requires access to the very system the regime is trying to hold to account.

Third, there is no compositional escape. Aggregating, filtering, or repackaging observational signals leaves them functions of observation. This holds even for the introspective case, where a model checks its own outputs against its own rules. Watching a system evaluate itself is still watching the system. The reasoning is not the authorization.

Two corollaries sharpen the point. Latency does not help: zero-latency observation is still observation. And interruption is not authorization: an architecture that halts a system upon observing an action attempt may prevent that execution, but a halt is not a verdict. It records that execution did not occur. It does not render a judgment, over a defined decision space, about whether the action was permitted.

The conclusion is compact. Observability explains what happened. Authorization determines what is allowed to happen. The two are complementary layers of a sound governance architecture, and neither substitutes for the other.

What authorization actually requires

If observability cannot authorize, what does authorization look like as an operational requirement rather than a slogan?

Before a consequential action executes, the system must produce a verdict in a closed space of exactly three values: ALLOW, DENY, or ABSTAIN. ABSTAIN is not a soft maybe. It carries fail-closed semantics: execution is blocked pending authorized human override. There is no fourth verdict, and escalation is not a verdict; escalation is the consequence of ABSTAIN, not a member of the space.

Fail-closed is definitional rather than optional. A boundary that lets an action proceed when authorization cannot be established is not an authorization boundary. The absence of a verdict means the absence of permission, not the presence of it.

This is what separates an authorization regime from a posture of disclosure, monitoring, or after-the-fact review. Those mechanisms may be useful, and a mature architecture will include them. They answer a different question. A log is not permission. A warning label is not permission. A supervisor somewhere in the organizational chart is not permission. A person who can later apologize, investigate, or remediate is not the same as an authority bound to the action before it executes.

The four tests a regime should ask

A serious authorization requirement can be stated as a short, vendor-neutral set of tests. The Four Tests Standard frames them as Stop, Ownership, Replay, and Escalation (FERZ, Four Tests Standard).

  • Stop. Can the system be halted before its effects are issued, with execution gated on an approval that exists first? This is fail-closed, pre-execution enforcement.
  • Ownership. Is an identified human authority bound to the governing policy before the execution window, with that policy's lineage fixed and auditable?
  • Replay. Can the verdict be reproduced at the boundary by an independent party, from the recorded state or protocol, without trusting the governed system's own account of what it did?
  • Escalation. On denial or on a threshold crossing, does custody transfer to an authorized human, rather than the action quietly proceeding?

These tests are not aspirational language. They are the operational projection of what an ex-ante regime structurally requires. A system that cannot demonstrate them is not governed by authorization, whatever it is called.

Use cases populate the regime; they do not replace it

None of this makes the use case irrelevant. Mental health, employment, credit, insurance, healthcare, education, and legal services carry different substantive obligations, and those obligations are real and specific.

  • A mental-health context may require licensed human authority, age-sensitive escalation rules, crisis routing, and strict limits on what the system may say or do.
  • A hiring context may require job-related criteria, bias constraints, auditability, and separation between screening assistance and employment decision authority.
  • A lending context may require explainability, fair-lending compliance, adverse-action logic, and evidence retention.

These are policy inputs. They populate the authorization regime. They do not change the architectural requirement: no pre-execution authorization, no execution.

A fair objection arises here. Selecting the right policy still requires classifying the use case, so doesn't this smuggle the naming game back in? It does not, and the difference is where the classification sits. Under category bans, the name is the control, and a successful renaming ends enforcement. Under an authorization regime, the name only selects which policy applies, while the boundary still demands a reconstructable verdict regardless of how the product describes itself. Misclassify the use case and you get the wrong policy. You do not get the absence of a boundary.

The gap, named precisely

The failure these proposals share has a name. The authorization artifact gap is the condition in which observability is relied upon to satisfy a requirement for pre-execution authorization (FERZ, Technical Advisory TA-2026-01). The test for closing it is a two-prong threshold: before execution, does a verdict exist; and can that verdict be reconstructed by an independent third party without access to the governed system (FERZ, The Authorization Artifact Test).

A system that fails either prong has not authorized anything. It has, at most, watched.

Conclusion

The future of AI regulation should not be an expanding list of forbidden labels. The list cannot keep pace with the market, and it attaches the control to a noun the governed system is free to change. The durable requirement is architectural: consequential AI actions should pass through a non-bypassable authorization boundary and leave behind an authorization artifact that an independent party can reconstruct.

No runtime authorization boundary, no fail-closed governance.

Ban unauthorizable systems, not the categories regulators happen to name first.


References

FERZ, Inc. On the Impossibility of Observability-Based Authorization. Concept DOI: 10.5281/zenodo.19647542.

FERZ, Inc. A Taxonomy of AI Governance Approaches: Distinguishing Visibility, Alignment, and Authorization. DOI: 10.5281/zenodo.18275969.

FERZ, Inc. Four Tests Standard (4TS), v1.0.3. SSRN: 10.2139/ssrn.5688982. Specification: github.com/edmeyman/4ts-standard.

FERZ, Inc. The Authorization Artifact Test. DOI: 10.5281/zenodo.20013582.

FERZ, Inc. Technical Advisory TA-2026-01: The Authorization Artifact Gap in AI Governance, Regulatory, and Audit Frameworks. Concept DOI: 10.5281/zenodo.20646404.