我把 FRIA 觸發判定做成規則，而非模型；模型演示效果本會更好

A note on my screen for two months read: does this need a FRIA? I left it unanswered, and the question was blocking someone else.

The person asking wasn't a lawyer. They were deploying an AI system inside an EU-facing business, and they needed one thing: is Article 27 going to land on me? Themes, evidence, checklist — all downstream of that.

That question became FriaForge. The first thing I got wrong was assuming the hard part was writing the assessment.

The first question is binary, and it is not "how risky?"

Article 27 of Regulation (EU) 2024/1689 puts a fundamental-rights impact assessment on deployers of certain high-risk AI systems before they put them into service. But you only reach that duty if your use case is in scope. So the first output of the tool cannot be prose. It has to be a call.

Three possible answers, no percentages: required, likely, not_indicated. I deliberately did not build a "moderate risk, 6 out of 10" answer. A score invites you to argue about the scale. A call is something you can argue about the facts, and I can show you the facts that produced it.

Three answers, and only three

The inputs are small on purpose: a description of how you deploy the AI system, the sector, whether a public authority is involved, and whether natural persons are affected. From those, the engine produces the trigger call.

Public authority, or a sector of public, credit, or insurance, gives required. Affects natural persons gives likely. Everything else lands on not_indicated.

There is also a floor on input quality: my own rule FRIA-01 flags any use case shorter than 60 characters, because a three-line paste gets you a call with nothing behind it.

Why three values instead of a gradient? Because a gradient hides the fact that the underlying criteria are categorical. When the call says not_indicated, that is a statement I can point at and you can check — not a number that feels like a finding.

Five blocks, and a pack that fails if one is missing

Every pack I return has the same five sections: Trigger call, Rights themes, Evidence gaps, Checklist, Honesty. Not "roughly these things" — the pack is validated against that section list, and a version missing a heading is rejected in favour of the rule-based one. That is the cheapest guard I know against a marketing-shaped document that lost its disclaimers.

Rights themes come from a fixed bank of three per sector. Credit gets access to essential private services, non-discrimination in scoring and pricing, and human review of adverse outcomes. If you flag a public authority in a non-public sector, an Art. 27(1) public-benefits theme is prepended, so four themes instead of three.

Evidence gaps start at four: map affected persons and vulnerable groups, list foreseeable rights harms and residual risk after mitigations, record human oversight design and appeal channels, and cross-check provider information for the DPIA and FRIA themes. When the call comes back not_indicated, a fifth gap appears telling you to re-check the sector and authority flags — which is the honest response to a weak input.

The checklist has four items: confirm whether the deployer seat is yours, handle Art. 26 duties separately, screen the vendor before you buy, and verify the outcome against the Article 27 primary text.

Why the trigger call runs without a model

My first instinct was to let a model read the use case and decide whether Article 27 applied. It would have produced nicer copy and a more impressive demo. I did not ship that.

The trigger call, the themes, the gaps, and the checklist are computed by a versioned rule engine — the current one is stamped 2026-10-22. Live mode lets a model rewrite the wording on top of that skeleton, and then the output goes back through the same section validation. If the rewrite dropped a heading, the rewrite is thrown away and you get the rule-based pack instead. If the upstream call fails you get a 502 with a degraded flag, not a plausible-looking document. If no key is configured you get a 503. Either way you get an error rather than a confident answer.

Six rule checks ride along with every run and print under the pack, including FRIA-01 (use case length) and FRIA-C2 (this is not a completed FRIA, not a DPIA, not legal advice).

The concession I will make: the model improves readability, and a document nobody finishes reading is a document that fails. So it stays — on the prose, and it has no say over the answer.

The 5-step flow I run before go-live

1. Paste how you deploy the AI system.
2. Set the sector, the public-authority flag, and the affects-persons flag.
3. Run the demo (rule-based) or a live run if one is configured.
4. Read the trigger call, the rights themes, and the evidence gaps.
5. Complete the FRIA with counsel before go-live.

Demo mode gives you a realistic sample; a live run uses the same structure with your real data. What I actually do with the output is hand the markdown to counsel as the first draft they argue with — the pack is a document to edit, not a document to sign.

What $19 a month actually buys

The tool is priced like the small utility it is: $19/mo, or $190/yr. You paste a use case, you get the five blocks, you export it as JSON or CSV and argue about it with counsel. The web form is backed by a REST endpoint, so a deployer can put the call inside their own pipeline — FriaForge runs in the browser with nothing to install.

What FriaForge is not

It is decision-support and a starter pack. It is not legal advice, not a completed FRIA, not a GDPR Art. 35 DPIA, and it does not replace qualified counsel.

The trigger call is a starting hypothesis, not a legal conclusion. If the tool says not_indicated and you are deploying something sensitive, that call is yours to own — verify it against the Article 27 primary text and against whoever signs the assessment. It does not file anything with a regulator, it does not watch your system after go-live, and it has no view of your vendor.

If you want the honest one-paragraph version: this tells you whether to open the FRIA conversation. It does not conduct the assessment for you.

FAQ

Q: Is the output a completed FRIA?
A: No. It is an Art. 27 starter pack with a trigger call, rights themes, evidence gaps, and a checklist. A completed FRIA is a documented assessment reviewed and signed by someone qualified, and that person owns it.

Q: Does the trigger call replace reading Article 27 myself?
A: No. It replaces the first hour of guesswork — the part where you work out whether the duty applies to your deployment at all. The pack itself tells you to verify the outcome against the primary text, and you should.

Q: What does it leave out?
A: Art. 26 deployer duties, which are a separate obligation; vendor screening, which happens before you buy rather than after you deploy; and a GDPR Art. 35 DPIA, which is a different legal instrument with a different scope.

Q: What happens if the live model call fails?
A: You get an error — a 502 for an upstream failure, a 503 when nothing is configured. You do not get a mock presented as your result.

References

• Regulation (EU) 2024/1689 (the AI Act) — EUR-Lex — the primary text, including Article 27.
• Article 27 — Fundamental rights impact assessment — the deployer obligation and its scope.
• European AI Office — how the obligations are meant to be applied consistently across Member States.
• FriaForge — the Art. 27 starter pack tool referenced above.