All articles

    Architecture note

    3 May 2026by Gustavo Teixeira Cuco4 min read

    Compliance Profiles

    Architecture context

    Reusable method

    Trust and compliance
    Compliance Profiles
    View on LinkedIn

    I build my products with AI tools โ€” Claude Code, Lovable, GitHub. The leverage is real. The blast radius, less talked about.

    I kept bolting compliance on at the end of every project. Privacy policy? Add it before launch. Audit log? Decide who owns it after the first incident. Data classification? Figure it out when a partner asks for it.

    That's the pattern most teams follow. It's also why audits hurt.

    I added a new layer to the governance template I use across these products. It addresses the part nobody wants to design upfront: compliance.

    The first instinct was to bake every framework into the base template. ISO 27001, GDPR, EU AI Act, IATI, HIPAA, ISO 13485. Make it comprehensive.

    That's wrong. A landing page doesn't need ISO 27001. A blog doesn't need ISO 42001. A pitch deck doesn't need IATI XML. Most of my products need none of them. The few that do need different combinations.

    What I added instead was profiles. The base template stays small. A flag in the ground rules activates obligations.

    compliance_profiles: security, ai-governance
    

    Each profile points at a directory of obligations and the controls that satisfy them. Four tiers.

    Tier 1 โ€” Universal. Always active. Data formats (ISO 8601, 4217, 639-1, 3166), accessibility (WCAG 2.2 AA), software quality model (ISO/IEC 25010). What every product inherits without thinking about it.

    Tier 2 โ€” AI Governance. Active when the product uses AI. EU AI Act (in force since August 2024, phased application through 2027), ISO/IEC 42001:2023 (the AI management system standard published December 2023), NIST AI RMF + GenAI Profile. A risk classification checklist runs before any AI product ships โ€” prohibited / high-risk / limited / minimal.

    Tier 3 โ€” Security & Privacy. Active when the workload is regulated, enterprise B2B, or government-facing. ISO 27001, SOC 2, GDPR, ISO 27701. With a clear distinction between aligned (controls implemented), certification-ready (gap assessment + audit trail), and certified (the organisation holds the certificate).

    Tier 4 โ€” Domain. Health (ISO 13485, IEC 62304, MDR, EHDS). Finance (ISO 20022, PCI DSS, PSD2). Climate (IATI, GHG Protocol, TCFD). Government (eIDAS, NIS2). Activate only the relevant one.

    The thing this clarified for me: ISO 27001 isn't a software feature. It's a management system. Of its 93 controls, maybe a third can live in code at all. The rest are policies, training, supplier management, internal audit โ€” work the organisation does, not the platform.

    The PaaS most AI-tool builders use likely already has SOC 2 Type II covering ~40 of those controls. The work I have to do is the other 30 โ€” and even then, most of it is identifying which controls apply, not inventing them. The AI does the implementation. I do the discipline.

    I keep relearning the same lesson with this template. Generic doesn't survive contact with specific. Comprehensive doesn't survive contact with the actual workloads. What survives is small + activatable.

    Compliance as configuration, not as a fork.

    The honest part: this doesn't make any product compliant. It makes the compliance work visible. Whether the controls actually get implemented, the policies get written, the people get trained โ€” that's still the work. The template just makes sure no one forgets which work applies, and to which product.

    Audit-readiness is architecture. The architecture is the governance template, not the codebase. Build it at the template level and the discipline propagates. Bolt it on at the end of each product and every quarter is a fire drill.

    What's your default compliance posture today โ€” and is it the one your next regulated workload will actually need?

    Template is open source โ€” link in the comments.


    Sources