Method  ยท  Trinzo AI Operating System

Sorting the AI Opportunity List

Deciding which candidates need governance and which need none

Status: method description

This describes how candidate AI uses are classified for suitability. It is a summary of the AI Front Door, drawn from the Trinzo AI Operating System. It contains no client engagement, no performance claim and no measured result. Effort ranges are the method's own planning guidance, not observed averages.

Most organisations do not have an AI implementation problem at the point I meet them. They have a sorting problem. There is a list, it is long, and everything on it is being treated as though it needs the same governance. That produces two failures at once: heavy process wrapped around work that never needed it, and light process around work that did.

The Front Door exists to sort that list before any method is opened. Its output is not an approval. It is a decision about where assurance should live, and for most candidates the answer is that it should stay exactly where it already is, with the professional doing the work.

Section 1At a glance

What it decidesThe lightest defensible route for a candidate AI use, before any implementation method is opened.
Who runs itThe professional describing the use, with a manager. Quality or Regulatory only where the regulated boundary is genuinely uncertain.
Four outcomesFD1 Professional Practice with AI, FD2 Controlled Regulated Workflow, FD3 Retain Unassisted, FD4 Do Not Pursue.
What it does not decideThe regulatory relationship. R0 to R3 routing happens inside the controlled method, after FD2 entry.
Recorded asAn AI Use Register entry per identifiable practice, not per interaction.
Typical effortFive minutes for a clear self-route. One to three hours for a facilitated session where the boundary is contested.

Section 2The four outcomes

CodeDispositionUse whenNext action
FD1Professional Practice with AINon-regulated individual or small-team knowledge work where trained professionals own the output.Keep assurance close to the work. Maintain capability, apply boundaries, record the practice.
FD2Controlled Regulated WorkflowAI materially supports work that may be examined by a regulator or inspector.Reference the standing organisational conditions and enter the controlled implementation method.
FD3Retain UnassistedThe human relationship, tacit judgement or professional reasoning is itself the point of the work.Keep the work human-led, or redesign the task so the judgement stays with the person.
FD4Do Not PursueAI does not solve the actual problem, the value case is weak, or the source conditions are poor.Stop the investment cheaply and fix the underlying condition first.

Only FD2 enters the controlled implementation method. FD1, FD3 and FD4 do not, and that is the point of running the sort at all.

Section 3What actually decides the route

Three things decide the route, and none of them is how advanced the technology is or how much time it might save.

The first is destination. Does the output stay an input to professional work, or does it materially affect a regulated record, a piece of inspectable evidence or a determination? The second is reliance. Does the professional independently own the reasoning, or would they be relying on the machine for a judgement they cannot themselves assess? The third is verifiability. Can a competent person establish whether the output is correct, complete and appropriate, at the volume the work actually runs at?

Consequence matters, but it enters later and it does not by itself decide the route. A Tier 3 consequence tells you how much assurance depth is warranted. It does not tell you whether the work belongs in the controlled method.

Section 4The three boundaries that keep FD1 safe

BoundaryProfessional ruleRe-route signal
ContentUse only approved tools and permitted information.New sensitive, confidential, personal, patient, controlled or licensed content exceeds the approved boundary.
DestinationAI output remains an input to professional work, not an authoritative regulated record.Output begins to materially affect regulated evidence, a controlled record or an inspectable determination.
ClaimsDo not represent AI output as proof of correctness, compliance or professional judgement.The person is expected to rely on the AI conclusion rather than independently own the reasoning.

Recognising a re-route signal is a user capability, not a governance activity. If people cannot spot these, the lightness of FD1 is not defensible.

This is also the point where the framework meets an external obligation rather than an internal preference. Article 4 of the EU AI Act, as rewritten by the Digital Omnibus and now in force as Regulation (EU) 2026/1744, requires providers and deployers to take measures supporting the development of AI literacy among staff operating these systems on their behalf. Market surveillance enforcement began on 2 August 2026.

The rewrite matters for this argument. Article 4 is now an obligation of effort rather than result: it explicitly does not require any particular level of literacy to be guaranteed for any individual. That is a closer fit for assurance resting on trained professionals recognising their own boundaries than the original wording was.

Section 5Where FD1 is not available

Some work products put FD1 out of reach whatever the intent behind the use. Content that will enter a complaint record, a CAPA record, batch release documentation or the body of a regulatory submission is inspectable regulated evidence, and AI that materially shapes it is FD2 by definition. There is no description of the destination that makes it otherwise.

The distinction is the work product, not the subject matter, and the difference is not pedantic. A professional restructuring their own private notes to think through a CAPA is not producing a CAPA record, and forcing that into the controlled method is the over-governance this sort exists to prevent. What matters is whether the output lands in the record.

Section 6Two rules that account for most errors

Two rules account for most of the routing errors I see.

The first is the bias rule for genuine ambiguity. Where the regulated or inspection boundary is genuinely uncertain, the person describing the use does not get to confirm FD1 themselves. The boundary question escalates and the affected work stays unassisted until it is answered. This is deliberately inconvenient. Self-confirmation under uncertainty is how regulated work quietly ends up on an unassessed path, and the people best placed to notice are rarely the people with an incentive to.

The second is that assurance location scales before the route changes. A non-regulated practice that grows from one person to a whole function has not become a regulated workflow. It has become a dependency. The correct response is to move assurance from individual to team to function to enterprise, and to make the concentration visible in the portfolio. Treating growth as though it were a change in regulatory character adds governance without adding safety, and it teaches people that being useful gets them audited.

Section 7Where assurance sits

LocationUse when
Individual professionalAd hoc or personal professional work within approved boundaries.
Small team or managerA repeatable shared practice is emerging across a small team.
Function or professional communityThe practice is common across a function, or requires specialist craft standards.
Enterprise practiceA non-regulated practice has become a common service or dependency across multiple functions.

Section 8What gets recorded

The register records identifiable practices, not individual prompts or interactions. Eight fields are the minimum:

  • Practice name and identifier, describing a recognisable unit of professional practice.
  • Accountable owner and function.
  • Front Door disposition: FD1, FD2, FD3 or FD4.
  • Assurance location: individual, team, function, enterprise or controlled workflow.
  • Routing basis: a short statement covering destination, verifiability and why that assurance location is right.
  • Approved tool and information boundary, referenced rather than restated.
  • Re-route triggers: the changes that would require a new Front Door decision.
  • Decision date and reviewer.

Recording every interaction produces a log nobody reads and a false impression of control. Recording practices produces something a manager can actually govern.

Two further fields are worth adding. They are recommended rather than part of the documented minimum, and the playbook should be updated before they are treated as required:

  • Next review date, so an entry cannot go stale silently.
  • Tool and model version at the time of the decision, so a routing decision can be read against the configuration it was made about.

Section 9What the register does not solve

The register does not solve shadow use, and it is better to say so than to imply otherwise. A register contains practices that people have described. Use that was never described is invisible to it, and existing live use is not grandfathered by having gone unnoticed for long enough. That is a containment problem, handled on entry to the controlled method by stabilising, inventorying and triaging what is already running, and it is not something a Front Door decision can reach.

Any organisation whose register looks complete within a few weeks of standing it up should treat that as a finding rather than an achievement.

Section 10The point of the exercise

The measure of a Front Door that is working is not how many candidates it lets through. It is how many it stops cheaply. FD4 is a success, not a failure, and so is FD3. An organisation that routes everything to the controlled method has not been careful. It has just moved the cost of its indecision onto the people doing the work.

Records and retention, supplier and platform qualification, audit trail and signature controls, and the linkage to corrective action all sit inside the controlled method and are handled in the playbook. They are out of scope here.

Candidates routed to FD2 continue into the controlled implementation method. Two illustrative examples of that method are set out in Post-Market Complaint Handling and Regulatory Submission Drafting. The reasoning behind the approach is developed in The AI Capability Series.

โ† All projects