# Eu AI Act Portfolio Impact > Regulatory impact assessment of an AI product portfolio against applicable AI governance classification requirements, identifying prohibited practices, high-risk system obligations, general-purpose AI model obligations, and systemic governance gaps. - Skill: `finchipaiorg/eu-ai-act-portfolio-impact` (Agent Skill) - Install (CLI): `npx skillmds@latest add finchipaiorg/eu-ai-act-portfolio-impact` - Raw SKILL.md: https://api.skillmd.com/api/skills/finchipaiorg/eu-ai-act-portfolio-impact/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: FinchipAIOrg (https://skillmd.com/u/finchipaiorg) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/finchipaiorg/eu-ai-act-portfolio-impact --- # Skill: AI Regulatory Impact on AI Product Portfolio ## 1. Subject-matter triage - Treat the assignment as a portfolio-level regulatory classification exercise, but analyze each AI offering separately before drawing any cross-portfolio conclusions. - If the source pack contains multiple products, models, deployments, or business lines, enumerate them up front and analyze each one on its own facts. - Distinguish whether the entity is acting as provider, deployer, importer, distributor, or downstream integrator for each item, because obligations attach differently by role. - Flag immediately whether any item appears to fall into a barred use, a high-risk use, or a general-purpose model track; these are distinct inquiries and may overlap. ## 2. Failure modes the skill is correcting - Accepting third-party assessments or internal labels without independently testing the actual functionality, deployment context, and legal category. - Collapsing all AI Act obligations into one compliance bucket instead of separating prohibited uses, high-risk systems, general-purpose model duties, and governance requirements. - Missing that one product may trigger more than one regime at once, so the analysis must not stop after the first match. - Treating documentation, oversight, logging, and risk management as optional or generic privacy-style controls rather than category-specific statutory obligations. - Overlooking provider-establishment issues that can trigger a representative-designation requirement for non-EU actors. - Failing to connect evidence of known harms, bias, or unsafe outputs to the enforcement-risk and governance-defect analysis. - Writing conclusions without anchoring them to the controlling AI Act provision or other applicable authority. - Delivering descriptions of issues without converting them into a severity-ranked memorandum and concrete action plan. ## 3. Legal frameworks / domain conventions that apply - Use the EU AI Act as the primary framework, and map each product to the correct legal bucket before discussing controls. - For prohibited practices, test whether the functionality fits a banned or narrowly excepted use, including manipulation, exploitation of vulnerabilities, certain biometric or emotion-related uses, and public-authority uses that fall within a prohibition. - For high-risk systems, assess the actual intended purpose and context against the Act’s listed categories and Annex-based use cases, not the marketing label. - For general-purpose AI models, analyze the separate provider duties that apply regardless of downstream deployment, including technical documentation, transparency support, copyright-policy expectations, and, where relevant, systemic-risk controls. - For high-risk systems, evaluate the continuous risk-management lifecycle, data governance, logging, technical documentation, human oversight, transparency, robustness, accuracy, and cybersecurity requirements. - For conformity assessment and market-access steps, determine whether the system can rely on internal controls or needs an external route, and whether registration or other pre-market steps apply. - For non-EU providers, assess whether a written representative in the Union is required before placing the system on the market. - Use the Act’s enforcement and penalty structure to map each identified breach to the correct tier of exposure. - When the source materials invoke sectoral or internal standards, treat them as supplements unless they conflict with the AI Act, in which case the statute controls. ## 4. Analytical scaffolds - Per-product classification: for each item, identify the function, user, deployment setting, provider role, and data flow; then test sequentially for prohibited-use status, high-risk status, and general-purpose model status. - Functional over label-based review: ignore product names and marketing claims unless they match the actual operation shown in the documents. - Biometric distinction: separate one-to-one verification from one-to-many identification, and test whether the deployment setting changes the outcome. - Emotion- and vulnerability-based review: assess whether the system is used in a context where sensitive inferences or exploitation concerns elevate the classification. - Employment, education, credit, insurance, access-to-services, law-enforcement, migration, and justice review: test whether the product’s actual decision-support or scoring function places it in a regulated high-risk category. - General-purpose model review: if the product is a foundation or general-purpose model, analyze its own obligations first; then determine whether downstream uses add a second layer of duties. - Governance review: test whether risk, ethics, or compliance committees have real decision authority, whether escalation works, and whether known issues are tracked to closure. - Documentation review: verify that technical files, instructions, testing evidence, logging design, and quality-management materials exist and are coherent, not fragmented or purely aspirational. - Remediation framing: convert each issue into a concrete compliance gap, then pair it with the legal consequence and the operational fix. ## 5. Vertical / structural / temporal relationships - Analyze obligations on the correct temporal plane: pre-market, placement-on-market, deployment, post-market monitoring, and incident response are not interchangeable. - Where the same product triggers multiple regimes, stack the duties rather than choosing one; a general-purpose model used in a high-risk application must satisfy both tracks. - Cross-check internal communications about bias, failures, unsafe outputs, or ignored recommendations against the formal governance record; informal awareness can aggravate the compliance picture. - If the documents include third-party classifications, compare them to the statutory criteria and explain any discrepancy rather than repeating the external conclusion. - Treat established-outside-the-Union status as a structural issue that can affect the representative analysis, enforcement posture, and implementation sequencing. - Where the source set contains multiple products or deployments, preserve product-by-product findings and then synthesize only after the individual analyses are complete. ## 6. Output structure conventions - Use a memorandum format with an executive summary, scope and assumptions, product-by-product analysis, portfolio-wide governance findings, risk ranking, and action plan. - Start with a short severity legend using a fixed ordinal scale, and apply that scale consistently to every issue. - For each product, state: what it is, who acts as provider/deployer, the legal classification, the controlling authority, the identified gap, the practical consequence, and the severity. - Separate per-product findings from cross-cutting governance findings so the reader can see which issues are system-specific and which are portfolio-wide. - Include a concise table or matrix that maps each product to its classification track, principal obligations, and current compliance status. - End with a Recommended Actions section that uses imperative verbs, identifies the responsible role or function, and ties each action to a timing anchor or regulatory milestone. - If the documents support multiple interpretations, present the alternative reading briefly, then state which interpretation is more defensible and why. - Keep the memorandum written for a business audience, but preserve legal precision and cite the controlling AI Act provisions or other applicable authority for each legal conclusion.