← Back

EU AI Act — Compliance Statement

Haakon & Haakon™ is legal-reasoning software from Fjell Systems AS, built for the person with the problem — not for the institution on the other side of it. On our assessment it is not a high-risk system under Annex III of the EU AI Act (Regulation (EU) 2024/1689): that Annex is a closed list, and the entries that come closest cover systems operated by or on behalf of courts and public authorities. Ours is operated by the individual.

We hold ourselves to the Chapter III requirements anyway, as voluntary alignment — because they are what a careful product does with someone's legal situation, not because we are compelled to. This page states honestly where that stands, including what is not done.

Dates, and the state of the law. The deferrals are now settled law, not a proposal we were tracking: Regulation (EU) 2026/1744 was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. What that means, in dates:

Annex III (stand-alone high-risk): 2 August 2026 → 2 December 2027
High-risk embedded in regulated products (Annex I): 2 August 2028
Regulatory sandboxes: 2 August 2027
Grace period for marking synthetic content: 2 December 2026 — this one was shortened from six months to three, so it moved toward us, not away
Article 50 transparency: 2 August 2026, unchanged. It was not deferred, and it applies to us whether or not anything here is high-risk. It is the only obligation on this page that is live within days.

We are stating the dates we are relying on so that you can check them against the Regulation, rather than asking you to take our summary on trust.

One precision, flagged rather than smoothed over. The deferral covers Chapter III Sections 1–3 (excluding Article 6(5)). Sections 4–5 — conformity assessment, CE marking, registration — were not textually deferred; they are practically inert while Section 2 is suspended, but “Article 43 is deferred to 2027” would be loose phrasing if anyone asked us precisely. We have flagged this for counsel rather than pick the convenient reading.

The Act is not yet in force in Norway — EEA incorporation is pending and the Norwegian implementing act has not been before Stortinget. We track the EU timetable rather than assert it as settled Norwegian law, and we will say so here when that changes.

Read the Act (EUR-Lex, official) Read the Omnibus, Reg. (EU) 2026/1744 (EUR-Lex) European Commission overview

Self-assessed · Last reviewed 2026-07-31 · Contact: craig@fjellsystems.com

Where we stand, article by article

Compliant in place today In progress being built toward the deadline Planned scheduled, not started Under legal review awaiting counsel

Obligation	What it requires	Status	Where we are
Art. 9 — Risk management	A continuous risk-management system across the lifecycle.	In progress	Two security audits worked off (both kill-chains closed); a formal, documented risk-management process is being structured.
Art. 10 — Data & data governance	Governance of training, validation and testing data sets.	Not applicable	Downgraded from “Compliant” on 30 July 2026 — it was answering a different question than the Article asks. Article 10 governs the training, validation and testing data of a high-risk system. We do not train, fine-tune or evaluate models on your case material: we send redacted text to a general-purpose model and keep the output. So most of Article 10 has no subject matter here, and claiming compliance with it credited us for work the Article does not ask of us. Our actual data-protection duties are live today under the GDPR, and they are stated in the next row rather than borrowed into this one.
GDPR Art. 5(1)(c) + Art. 25 — Data minimisation & protection by design	Process no more personal data than you need; build the safeguards in.	In progress	This is the honest home for the redaction promise, and unlike the AI Act it is in force in Norway now. Personal data is removed before case text reaches a model, and the pipeline refuses to run when the redactor is unavailable rather than proceeding unprotected. Case material is stored in Norway; redacted text is processed in the EU/EEA (Azure Data Zone). Two things stated plainly instead of an absolute: redaction is measured, not assumed — we publish recall figures rather than claiming perfection — and audio transcription reads the raw recording inside our own boundary before redaction applies. “In progress” because the default protection profile for documents is still being settled; this row gets its final wording when that decision lands.
Art. 11 + Annex IV — Technical documentation	A structured technical file describing the system.	In progress	The architecture is documented; formalising it into the Annex IV structure is in progress.
Art. 12 — Record-keeping (logging)	Automatic, tamper-evident logging of events over the system's lifetime.	In progress	Downgraded from “Compliant” on 30 July 2026, because the scope was wider than what we built. What exists is real: Vör-Log writes security-relevant events — access, authentication, role changes, redaction approvals — to a hash-chained, append-only trail, so any retroactive edit breaks the chain, and Vör-Report produces the record on demand. What Article 12 asks for is broader: traceability across the system's whole lifecycle, not only its security events. That gap is named here rather than hidden behind the part we did finish.
Art. 13 — Transparency & instructions	Users can interpret output; instructions for use are provided.	In progress	Output is structured guidance (not raw model text). Formal instructions-for-use are being written.
Art. 14 — Human oversight	Humans can understand, monitor, and override the system.	Compliant	The system never acts autonomously — every output is a draft the user reviews and confirms. A per-file human approval gate governs cloud processing; an adversarial review layer (Tyr) flags errors; users can correct any output; Vör logs oversight actions.
Art. 15 — Accuracy, robustness & cybersecurity	Appropriate accuracy, resilience, and security.	In progress	Fact-sheet anchoring constrains the model to verified values; security hardening shipped; Vör-Watch detects suspicious access. Formal accuracy metrics are still to be documented.
Art. 16–21 — Provider obligations & quality management	A quality-management system and provider duties.	In progress	Being formalised alongside the technical documentation.
Art. 43 / 47 / 48 — Conformity, declaration & CE marking	Self-assessment, a declaration of conformity, and CE marking.	Not applicable	These follow from a high-risk classification. On our assessment H&H is not an Annex III system, so there is no basis on which to affix a CE mark — and claiming one we are not entitled to would be worse than claiming none.
Art. 49 — EU database registration	Registration in the EU high-risk database before deployment.	Not applicable	The high-risk database is for high-risk providers; it is not something a system outside Annex III can usefully register in.
Art. 50 — Transparency (applies in the EU from 2 August 2026)	Telling people they are interacting with an AI system, and marking AI-generated content where that applies.	In progress	This is the one obligation on this page that goes live within days, and it was not deferred. To be precise about where it stands: it binds providers serving users in the EU from 2 August 2026. It is not yet binding in Norway, where the AI Act awaits incorporation into the EEA Agreement and a Norwegian implementing act. We treat it as binding from that date regardless. How we meet it: Freyja, the assistant you talk to in H&H, is an AI system with a name — not a person, and never presented as one. She says what she is when you first meet her, and a persistent line under the message box states it throughout every conversation, so the identification does not depend on remembering the first message. The wording is checked against the European Commission's guidelines of 20 July 2026 and written in Norwegian, not translated from a mockup. Beyond identification, nothing Freyja produces acts on its own. Every draft is reviewed and released by you before it counts, every document you share carries a line stating that AI was involved and who released it, and a letter you file in your own name stays visually yours — you are the author and the paper says so. On Article 50(2) — machine-readable marking of AI-generated content — we promised to publish a conclusion here either way, and here it is: the duty applies to us as the system's provider, and we meet it by marking rather than by arguing exemptions (position of 11 August 2026, revised 12 August, with counsel for confirmation). Concretely: the exported PDF letter will carry a machine-readable provenance note in its document metadata — recording that AI assisted the draft and a person reviewed and approved it — while the visible page stays entirely yours; and the AI-generated surfaces inside the product get a machine-readable layer to match their visible labels, built to the format of the Commission's Code of Practice on Transparency of AI-generated Content. The law gives this a deadline: the marking grace period ends 2 December 2026. This row stays “In progress” until both marks are shipped, not because the position is uncertain but because a status badge here describes what is built, not what is intended.
GDPR Art. 22 — Automated decision-making	A legal basis where a decision is solely automated.	Under legal review	Our reading is that Article 22 is probably not engaged: it governs decisions made about a person, and nothing here decides anything about you — the output is your own working material, aimed at the institution on the other side. We are saying “probably” rather than “no” because it is counsel's call and it has not been made yet. Mitigated meanwhile: every output is a non-binding draft until a human confirms it.
GDPR Art. 35 — Data protection impact assessment	A written DPIA where processing is likely to be high-risk to people.	In progress	Added to this page on 30 July 2026 because it was missing and should not have been. A DPIA is the instrument that most clearly applies to us: special-category data (health, family, immigration status) about people in vulnerable situations, at scale. It has not been written yet. It is owed before the pilot widens beyond invited users.

What is not yet in place

In plain terms, and in the order they matter:

The persistent “you are talking to an AI” notice under the message box — the one Article 50 item on a deadline of days rather than years.
The data protection impact assessment (GDPR Article 35). Not written. Owed before the pilot widens beyond invited users.
The Article 6 classification assessment that this page's whole position rests on. We have stated our reasoning here; the formal written assessment behind it is still to come.
Lifecycle traceability beyond security events (Article 12), the Annex IV technical file, the documented risk-management process, and formal accuracy metrics.
Counsel's confirmation on GDPR Article 22, and the written position on whether machine-readable marking applies to per-user drafts.

What we changed, and what we got wrong

Three rows were downgraded on 30 July 2026, and none of it was because the system got worse. We had graded ourselves against the wrong questions, and a status badge that flatters is worse than no page at all.

Article 10 went from “Compliant” to “Not applicable”. We had put our redaction work there. But Article 10 is about the data you train a system on, and we do not train on your case material — so we were taking credit under an Article that does not ask us for it. The redaction promise moved to the GDPR rows, where it is actually owed, and where it is already in force in Norway.
Article 12 went from “Compliant” to “In progress”. Our audit trail is real and tamper-evident, but it covers security events; Article 12 wants traceability across the whole lifecycle. The part we finished was being used to imply the part we had not.
Article 50 stays “In progress”, and we have said exactly why. The disclosure is currently in Freyja's opening message, which scrolls away. Naming that is more useful to you than a green badge.

We also added a row we had simply been missing — the GDPR Article 35 impact assessment — rather than let its absence read as “not required”.

And one thing this page cannot fix by itself. The corrections described here were written on 29–30 July 2026, but a page only tells the truth once it is deployed. If you are reading an older version of this statement — check the reviewed date above — then the classification it describes may be the one we have since withdrawn. We are recording that risk here because we hit it ourselves.

What we removed from this page, and why. An earlier version said H&H was treated as a high-risk system under Annex III, and listed CE marking and EU-database registration as scheduled work. We no longer think that is right: Annex III is a closed list, and the entries that come closest turn on who operates the system — courts and public authorities. H&H is operated by the individual, against those institutions. Claiming high-risk status looked like the cautious choice and was not: it is inaccurate, and it commits us to a CE mark we have no basis to affix. We would rather be checkable than impressive.

Data sources. Legal texts — current Norwegian laws and central regulations — are sourced from Lovdata and used under the Norwegian Licence for Open Government Data (NLOD 2.0). Source: Lovdata (NLOD 2.0).

This is a good-faith self-assessment, not legal advice or a certification. It is reviewed as the system changes. Norway/EEA adoption of the Act may follow the EU dates via the EEA Joint Committee; we track any divergence.