EU AI Act (framework self-assessment)

⚡ Generate from source material ⬇ Export .yarnpack.json Advanced: raw JSON

Metadata

Scales, categories & audiences

Scales: maturity5 (5 levels) · Categories: scope transparency highrisk · Audiences: lead owner exec

Edit these in the raw JSON editor below — they change rarely and carry structure (levels, signals, deep-dive wiring) that a form would mangle.

EU AI Act elements core

Everyone answers these. Board or executive sponsor, legal and privacy (GDPR runs in parallel), procurement and contract owners, product or system owners who know where output is used, and the data governance lead.

Id	Question	Type	Category	Scale
euaiact-1	Walk me through where AI is in use here, including tools your vendors supply. For each one, could anyone in the EU end up using what it produces, and did you build it or just use it?	scored_text · scored	scope	maturity5
euaiact-2	Pick three AI systems you run. Which of the Act’s tiers is each in, who decided, and what did they write down? Is any of them used in employment, education, essential services, biometrics or law enforcement?	scored_text · scored	scope	maturity5
euaiact-3	Does anything you run read people’s emotions, score them on behaviour, scrape faces from the web or generate images of real people? How would you know if a vendor tool started doing that?	scored_text · scored	scope	maturity5
euaiact-4	When a customer chats with your bot or reads a summary your AI wrote, how do they find out it was AI? Who checked that last month, and against what?	scored_text · scored	transparency	maturity5
euaiact-5	Which foundation models sit under your AI tools, and who supplies them? What have those providers actually given you in writing, and what does the contract say they must tell you when the model changes?	scored_text · scored	transparency	maturity5
euaiact-6	For the system you would call highest risk, show me the risk list. When was it last updated, what changed, and who signed off the residual position?	scored_text · scored	highrisk	maturity5
euaiact-7	What data did this system learn from or draw on, who owns it, and how did you satisfy yourself it reflects the people it will be used on? What happens when an error is found in it?	scored_text · scored	highrisk	maturity5
euaiact-8	If a regulator asked you next week to explain what this system is and to show what it did on a given day last month, what would you hand over, and how long would it take to find?	scored_text · scored	highrisk	maturity5
euaiact-9	For a high-risk system you supply or run, where are the instructions for use? Who wrote them, what do they say it must not be used for, and when did they last change?	scored_text · scored	highrisk	maturity5
euaiact-10	When this system gets it wrong, who notices, how fast, and what can they actually do about it? Has anyone ever overridden it, and is that written down?	scored_text · scored	highrisk	maturity5
euaiact-11	How accurate is this system, how do you know, and what happens to that number when the inputs get strange or someone tries to game it? When was it last tested?	scored_text · scored	highrisk	maturity5
euaiact-12	Which of your systems will need a conformity assessment and CE mark before Dec 2027 or Aug 2028? Who owns that plan, and what would tell you after go-live that something has gone wrong?	scored_text · scored	highrisk	maturity5

＋ Add question to “EU AI Act elements”

Add section

Advanced — raw JSON

Full pack document, validated on save (schema yarn-pack/2). This is where scales, audiences, structured conditions and adaptive config live.

{
  "schema": "yarn-pack/2",
  "id": "framework-euaiact",
  "version": "0.1.0",
  "name": "EU AI Act (framework self-assessment)",
  "engagement": "AISG — framework self-assessment: workshop prep, workshop, or diagnostic strand",
  "intro": "A guided conversation against EU AI Act, not a form. Answer in your own words and name the document or record that shows it if you can. About 24 minutes. Self-assessment against Regulation (EU) 2024/1689 as amended by Reg (EU) 2026/1744: scope and tiering, the live Article 50 and GPAI duties, and the deferred high-risk stack. Not legal advice; not a GDPR or DPIA check.",
  "tone_default": "professional",
  "prefill_fields": {
    "department": [
      "Executive",
      "Finance",
      "Operations",
      "Customer / Sales",
      "Technology / IT",
      "Data & Analytics",
      "People & Culture",
      "Risk & Compliance",
      "Marketing",
      "Product"
    ]
  },
  "scales": [
    {
      "id": "maturity5",
      "name": "Maturity (distilled model)",
      "levels": [
        {
          "value": 1,
          "label": "Does not exist",
          "gloss": "No capability. Absent, or purely ad hoc / accidental."
        },
        {
          "value": 2,
          "label": "Partially exists",
          "gloss": "Emerging and inconsistent. Pockets of activity, not joined up."
        },
        {
          "value": 3,
          "label": "Fully exists",
          "gloss": "Defined, documented and operating across the organisation."
        },
        {
          "value": 4,
          "label": "Fully exists & optimised",
          "gloss": "Measured, refined and improving against targets."
        },
        {
          "value": 5,
          "label": "Fully exists & adaptive",
          "gloss": "Continuously self-adjusting; a source of advantage."
        }
      ],
      "signals": {
        "1": [
          "no ",
          "not ",
          "none",
          "never",
          "don't",
          "do not",
          "nothing",
          "absent",
          "unaware",
          "haven't",
          "ad hoc",
          "ad-hoc",
          "nonexistent",
          "no idea",
          "not really"
        ],
        "2": [
          "some ",
          "starting",
          "beginning",
          "emerging",
          "pilot",
          "trial",
          "informal",
          "inconsistent",
          "pockets",
          "a bit",
          "occasionally",
          "early",
          "experiment",
          "trying",
          "patchy"
        ],
        "3": [
          "documented",
          "defined",
          "standard",
          "standardised",
          "established",
          "policy",
          "framework",
          "process",
          "consistent",
          "across the",
          "in place",
          "formal",
          "governed",
          "rolled out"
        ],
        "4": [
          "measured",
          "metrics",
          "optimis",
          "improving",
          "kpi",
          "monitored",
          "reviewed",
          "refined",
          "benchmarked",
          "targets",
          "tracked",
          "mature",
          "regularly review"
        ],
        "5": [
          "continuous",
          "adaptive",
          "self-",
          "automated end",
          "best in class",
          "best-in-class",
          "competitive advantage",
          "industry leading",
          "always",
          "real-time monitoring",
          "feedback loop"
        ]
      }
    }
  ],
  "categories": [
    {
      "id": "scope",
      "name": "Scope and tiering",
      "order": 1,
      "target_default": 3
    },
    {
      "id": "transparency",
      "name": "Transparency and GPAI",
      "order": 2,
      "target_default": 3
    },
    {
      "id": "highrisk",
      "name": "High-risk stack",
      "order": 3,
      "target_default": 3
    }
  ],
  "audiences": [
    {
      "id": "lead",
      "name": "Governance / risk lead",
      "desc": "Owns the policy, the register or the risk framework",
      "deep_dive_sections": []
    },
    {
      "id": "owner",
      "name": "System or use-case owner",
      "desc": "Runs an AI system or use case day to day",
      "deep_dive_sections": []
    },
    {
      "id": "exec",
      "name": "Executive / sponsor",
      "desc": "Accountable for the outcome, not the mechanics",
      "deep_dive_sections": []
    }
  ],
  "sections": [
    {
      "id": "core",
      "title": "EU AI Act elements",
      "blurb": "Everyone answers these. Board or executive sponsor, legal and privacy (GDPR runs in parallel), procurement and contract owners, product or system owners who know where output is used, and the data governance lead.",
      "optional": false,
      "questions": [
        {
          "id": "euaiact-1",
          "type": "scored_text",
          "category": "scope",
          "name": "AI system inventory and EU exposure",
          "text": "Walk me through where AI is in use here, including tools your vendors supply. For each one, could anyone in the EU end up using what it produces, and did you build it or just use it?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "No inventory of AI systems exists; nobody can say which systems have EU customers or EU-used output, or whether the organisation is a provider or a deployer.",
            "3": "An inventory lists every AI system and GPAI model with an owner, its EU exposure (market or output used in the EU) and the organisation’s role on each row.",
            "5": "New systems, vendor changes and new EU customers update the inventory and its exposure calls as they occur; role and exposure are re-tested on a set cycle."
          },
          "help": "Evidence that would show it: Master use case register with EU exposure and role columns; Vendor and third-party AI register; Shadow AI register with remediation pathway; Customer or market list showing EU-based users of AI output.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "euaiact-2",
          "type": "scored_text",
          "category": "scope",
          "name": "Honest risk tiering",
          "text": "Pick three AI systems you run. Which of the Act’s tiers is each in, who decided, and what did they write down? Is any of them used in employment, education, essential services, biometrics or law enforcement?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "No system has been tiered; teams either assume everything is high risk or assume nothing is caught, and no method or record supports either view.",
            "3": "Every inventoried system carries a tier with a written rationale against the Act’s tiers, signed off by an accountable owner; minimal tools carry no extra controls.",
            "5": "Tiering runs at intake and on material change; the method is updated as the Act, the Omnibus and Commission guidance move, and past calls are re-tested against it."
          },
          "help": "Evidence that would show it: Use case risk classification method referencing the Act’s tiers; Tier column and rationale on the use case register; Intake form capturing Annex III uses (employment, essential services, biometrics); Sign-off record for tier decisions.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "euaiact-3",
          "type": "scored_text",
          "category": "scope",
          "name": "Prohibited practices screening",
          "text": "Does anything you run read people’s emotions, score them on behaviour, scrape faces from the web or generate images of real people? How would you know if a vendor tool started doing that?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "No prohibited-practice check exists at intake or in review; nobody can say whether any system does emotion recognition at work or social scoring.",
            "3": "An Article 5 screen runs at intake and over the existing estate; every system has a recorded result, and staff-facing rules name the prohibited practices.",
            "5": "The screen is updated when Article 5 changes (the Omnibus additions were picked up inside the transitional period) and re-run across the estate without prompting."
          },
          "help": "Evidence that would show it: Article 5 screening checklist in the intake form or stage gate; Acceptable use guideline listing the prohibited practices; Screening result recorded per system on the register; Technical safeguards for the NCII and CSAM prohibition, ahead of 2 Dec 2026.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "euaiact-4",
          "type": "scored_text",
          "category": "transparency",
          "name": "Article 50 transparency duties",
          "text": "When a customer chats with your bot or reads a summary your AI wrote, how do they find out it was AI? Who checked that last month, and against what?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "Customers and staff are not told when they are dealing with a chatbot or reading AI-generated content; no register says which systems trigger Article 50.",
            "3": "Every limited-tier system on the inventory has its disclosure or label in place, checked against the Commission’s 20 Jul 2026 guidelines, with an owner per system.",
            "5": "Disclosure is built into the intake gate for any customer-facing AI; notices and labels are reviewed against new Commission guidance and user complaints as they arrive."
          },
          "help": "Evidence that would show it: Disclosure and transparency mechanism, with the Article 50 systems named; Screenshots or copies of the notices and labels in use; Register column flagging each system’s Article 50 trigger; Check of notices against the Commission’s Article 50 guidelines.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "euaiact-5",
          "type": "scored_text",
          "category": "transparency",
          "name": "GPAI procurement and provider documentation",
          "text": "Which foundation models sit under your AI tools, and who supplies them? What have those providers actually given you in writing, and what does the contract say they must tell you when the model changes?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "GPAI models arrive inside products and subscriptions with no record of which model, which provider, or what documentation the provider offers.",
            "3": "Every GPAI model in use is on the register with its provider, the provider’s transparency and copyright documentation on file, and contract clauses requiring it.",
            "5": "Provider documentation is refreshed on material change; whether a provider signed the GPAI Code of Practice is tracked and weighed in vendor selection."
          },
          "help": "Evidence that would show it: Vendor and third-party AI register naming the GPAI model and provider per system; Vendor AI clauses requiring transparency and copyright documentation; Material change notification process with provider notices on file; Approved tooling and model list.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "euaiact-6",
          "type": "scored_text",
          "category": "highrisk",
          "name": "Risk management system",
          "text": "For the system you would call highest risk, show me the risk list. When was it last updated, what changed, and who signed off the residual position?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "No AI-specific risk process exists; risks are raised ad hoc at go-live, if at all, and nothing is revisited once a system is in service.",
            "3": "Each high-risk system has a live risk register with treatments, owners and residual ratings, reviewed on a set cycle across design, deployment and operation.",
            "5": "Risk reviews are triggered by monitoring signals, incidents and model changes, not only the calendar, and the process itself is revised from what those reviews find."
          },
          "help": "Evidence that would show it: AI risk register entries per high-risk system with treatment and residual rating; Controls library mapping risks to controls with owners; Lifecycle SOPs showing risk review at each stage; Review minutes showing the register was revisited after go-live.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "euaiact-7",
          "type": "scored_text",
          "category": "highrisk",
          "name": "Data and data governance",
          "text": "What data did this system learn from or draw on, who owns it, and how did you satisfy yourself it reflects the people it will be used on? What happens when an error is found in it?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "Nobody can name the datasets behind the system, who owns them, or whether anyone checked them for relevance, representativeness or errors.",
            "3": "Each dataset behind a high-risk system has a named owner, a documented relevance and representativeness check, and an error-handling record kept current.",
            "5": "Data quality and representativeness are monitored in production; drift or bias findings feed back into data governance and the datasets are re-certified."
          },
          "help": "Evidence that would show it: Corpus or dataset register with ownership and refresh cadence; Data quality and representativeness assessment per high-risk system; Model card recording data sources and known limitations; Content sensitivity tagging and exclusion rules applied before use.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "euaiact-8",
          "type": "scored_text",
          "category": "highrisk",
          "name": "Technical documentation and record-keeping",
          "text": "If a regulator asked you next week to explain what this system is and to show what it did on a given day last month, what would you hand over, and how long would it take to find?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "No technical documentation exists beyond vendor marketing or code comments; logs are not kept, or are overwritten before anyone could reconstruct a decision.",
            "3": "Each high-risk system has current technical documentation under version control and automatic logs, retained for a defined period, that let an operation be traced.",
            "5": "Documentation is regenerated from the build pipeline on each release; log coverage and retention are tested, and gaps found in incident reviews change the logging design."
          },
          "help": "Evidence that would show it: Model card or technical file per high-risk system, version-controlled; Logging specification and retention setting for the system; Sample log extract showing an operation traced end to end; Verification log showing documentation and logging checks.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "euaiact-9",
          "type": "scored_text",
          "category": "highrisk",
          "name": "Transparency and instructions for deployers",
          "text": "For a high-risk system you supply or run, where are the instructions for use? Who wrote them, what do they say it must not be used for, and when did they last change?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "Systems ship to deployers, or arrive from providers, with no instructions for use; limits and intended purpose are known only to the build team, if at all.",
            "3": "Each high-risk system has written instructions for use naming intended purpose, limits and operating conditions, issued to every deployer and held from every provider.",
            "5": "Instructions are updated on every material change and re-issued; deployer questions and misuse reports feed back into the next version."
          },
          "help": "Evidence that would show it: Instructions for use or model card issued with each high-risk system; Provider instructions on file for each high-risk system deployed; Material change notices tied to instruction updates; Disclosure mechanism describing the system to those who run it.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "euaiact-10",
          "type": "scored_text",
          "category": "highrisk",
          "name": "Human oversight",
          "text": "When this system gets it wrong, who notices, how fast, and what can they actually do about it? Has anyone ever overridden it, and is that written down?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "Outputs flow to decisions with no named human responsible for checking them; no one can say whether a person could stop or override the system.",
            "3": "Each high-risk system has a documented oversight model (in, on or out of the loop) with rationale, named overseers, and a tested way to intervene.",
            "5": "Oversight effectiveness is measured (override rates, missed errors) and the model is tightened or loosened on that evidence; overseers rotate and refresh."
          },
          "help": "Evidence that would show it: Human oversight model per use case with rationale; Stage-gate criteria requiring an oversight decision before deploy; Record of overrides or interventions on the system; Role description for the overseeing person.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "euaiact-11",
          "type": "scored_text",
          "category": "highrisk",
          "name": "Accuracy, robustness and cybersecurity",
          "text": "How accurate is this system, how do you know, and what happens to that number when the inputs get strange or someone tries to game it? When was it last tested?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "No accuracy target exists; the system was not tested under adverse or unusual inputs, and its security was never assessed apart from the wider IT estate.",
            "3": "Each high-risk system has declared accuracy metrics with test results, robustness testing on record, and a security assessment; all three are re-run on a set cycle.",
            "5": "Accuracy, robustness and security are monitored in production with thresholds that trigger review; adversarial tests and findings change the system and the tests."
          },
          "help": "Evidence that would show it: Test results against declared accuracy metrics per system; Robustness and adversarial test records; Security assessment or penetration test for the system; Verification log showing periodic re-testing.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "euaiact-12",
          "type": "scored_text",
          "category": "highrisk",
          "name": "Conformity, CE mark and post-market monitoring",
          "text": "Which of your systems will need a conformity assessment and CE mark before Dec 2027 or Aug 2028? Who owns that plan, and what would tell you after go-live that something has gone wrong?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "No plan exists for conformity assessment, CE marking or EU database registration; nothing monitors the system once it is live beyond uptime.",
            "3": "Each high-risk system has a conformity assessment plan with owner and date ahead of its deferred deadline, and a running post-market monitoring process.",
            "5": "Post-market signals, incidents and complaints trigger re-assessment; the conformity file is kept current with each change and an independent challenge tests it."
          },
          "help": "Evidence that would show it: Assurance schedule showing conformity assessment activities and dates; AI incident register feeding post-market monitoring; Independent challenge or external assurance record; Use case register flagging systems that will need EU database registration.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        }
      ]
    }
  ],
  "grids": {},
  "outputs": [
    "Level per element and per category, gated",
    "Contested-element view (spread of 2 or more)",
    "Coverage of evidence: confirmed, stated, inferred",
    "Where to start, foundations first",
    "Printable client report"
  ],
  "report_defaults": [
    "rpt-maturity-standard"
  ],
  "playbook": {
    "sequence": [
      "scope",
      "transparency",
      "highrisk"
    ],
    "sequence_note": "Inventory, tier honestly and confirm EU exposure and role first; most of what you run is minimal or limited. Then close the live Article 50 and GPAI gaps. Only then plan the deferred high-risk stack.",
    "actions": {
      "scope": {
        "to_3": [
          "Inventory every AI system and GPAI model, including vendor-supplied and shadow tools",
          "Tier each system honestly against the Act’s tiers with a written rationale; do not gold-plate minimal tools",
          "Confirm EU exposure and your role (provider or deployer) per system",
          "Screen the estate against Article 5, including the Omnibus NCII and CSAM additions"
        ],
        "to_5": [
          "Run tiering, exposure and Article 5 screening at intake and on material change, and re-test past calls as the Act moves"
        ]
      },
      "transparency": {
        "to_3": [
          "Put disclosure and labels on every chatbot, deepfake and AI-generated output, checked against the Commission’s Article 50 guidelines",
          "Write provider documentation and material change clauses into GPAI contracts, and collect the documents"
        ],
        "to_5": [
          "Layer marking methods for AI-generated content: no single technique meets the Act’s standard; marketed systems are caught from 2 Dec 2026",
          "Track which GPAI providers signed the Code of Practice and weigh it in selection"
        ]
      },
      "highrisk": {
        "to_3": [
          "Map gaps for high-risk and EU-facing systems, reusing ISO 42001 and 27001 controls; a 42001 AIMS is a scaffold, never a legal substitute",
          "Set a conformity assessment plan per high-risk system ahead of 2 Dec 2027 (Annex III) or 2 Aug 2028 (Annex I)",
          "Track the Digital Omnibus and Commission guidance for changes to the stack"
        ],
        "to_5": [
          "Wire post-market monitoring, incidents and model changes into risk review, documentation and re-testing so the stack updates itself"
        ]
      }
    }
  }
}

EU AI Act (framework self-assessment) v0.1.0

Metadata

Scales, categories & audiences

EU AI Act elements core

Add section

Advanced — raw JSON