Coder Legion - Recent posts tagged compliance

Free AI Policy Template (UK): Every Rule Has a Control

Thu, 29 Oct 2026 07:53:03 +0000

This article was originally published on korixinc.com.
Read the canonical version at: https://korixinc.com/learning-center/ai-policy-template-uk

Free AI Policy Template (UK): Every Rule Has a Control

A policy is only as strong as the control behind each rule. This free UK AI policy template pairs every clause with the control that enforces it and the evidence you would show.

If a client asked how you know your staff are not pasting their data into ChatGPT, a signed policy would not answer them. This free AI policy template for UK businesses is built so you can: every rule comes with the control that enforces it and the evidence you would show. Copy the clauses, name an owner for each control, and you have an answer.

You almost certainly need one already. Microsoft research carried out by Censuswide in October 2025 found that 71% of UK employees have used unapproved consumer AI tools at work, and 51% do so every week, across a sample of 2,003 UK employees. Only 32% said they were concerned about the privacy of the company or customer data they put into those tools. Your team is using AI whether or not anyone wrote a rule about it; the policy decides whether that use is visible and defensible.

Most firms have not caught up. In ISACA's 2026 AI Pulse Poll of more than 3,400 digital trust professionals, only 38% of organisations had a formal, comprehensive AI policy, up from 28% in 2025. Another 30% had a limited policy and 25% had none at all, while 90% of respondents believed employees in their organisation were using AI.

A note on who wrote this, because it matters for how you read it. KORIX builds governed AI systems for UK service firms, so we have a commercial interest in AI being done properly. The template below is free, it works without us, and nothing in it requires you to buy anything. It is not legal advice either: if you are regulated by the FCA, the SRA or a similar body, have your compliance lead or adviser check the final version against your own obligations.

What should an AI policy include?

An AI policy should cover which tools are approved, which data can never go into them, when a human must check AI output, who owns AI risk and what happens when something goes wrong. Each of those needs a control that enforces it, not just a sentence that describes it.

Most templates you will find online stop at the sentence. They tell staff not to paste client data into public AI tools, ask them to sign, and file the signed copy. That gives you a record that you told people, which is useful after an incident, but it does nothing to stop the incident. The question a client, an insurer or the ICO will actually ask is not whether you had a policy, but how you knew it was being followed.

KORIX defines an enforceable AI policy as one where every rule names a control, an owner and the evidence that proves the control is working. Those three parts are what turn a document into a system:

The control is the mechanism that makes the rule hard to break: a blocked website, a business account with the right settings, an approval step in a workflow, a log that records what happened.
The owner is one named person, not a department, who is accountable for the control working.
The evidence is what you would show someone to prove it: an admin report, an approval log, a training record, a review date that actually happened.

If a rule in your policy has all three, it will survive scrutiny. If it has only the sentence, treat it as a wish and either add a control or accept the risk openly.

The free AI policy template (copy and adapt)

Copy the clauses below into your own document and replace the bracketed parts. Each clause has the policy wording first, then the control that enforces it and the evidence to keep.

Section 1. Purpose and scope

Policy wording: This policy sets out how [Company name] staff, contractors and anyone acting on our behalf may use artificial intelligence tools, including generative AI chatbots, writing assistants, transcription tools, coding assistants and AI features built into software we already use. It applies to all work for the company and all company or client data, on any device.

Control: The policy is issued through your normal HR or onboarding system and acknowledged by every person in scope.

Evidence: the acknowledgement record, kept with the policy version number.

Section 2. Approved tools

Policy wording: Staff may only use the AI tools listed in the Approved AI Tools Register, through company-managed accounts. Using personal accounts or unlisted AI tools for company work is not permitted. Anyone may request that a tool be added; requests go to [AI owner].

Control: Keep the register as a single live document with an owner. Provide business accounts for the approved tools so staff have a sanctioned option that is as easy as the consumer one. Where your IT setup allows it, restrict access to unapproved AI sites on managed devices.

Evidence: the register with dates of each approval, and the admin console showing who has an account.

The request route matters as much as the ban. If asking for a tool is slow or unclear, people will use the consumer version quietly, which is exactly the problem this clause exists to solve.

Section 3. Data you must never put into an AI tool

Policy wording: The following must never be entered into any AI tool unless that specific tool and use has been approved for it in the register: client personal data; special category data such as health information; financial account details; passwords, keys or access credentials; information covered by a confidentiality agreement; and unpublished company financial information.

Control: Use business tiers of approved tools and read their terms on whether your inputs are used for training and how long they are retained, then record what you found in the register. For higher-risk data, use data loss prevention rules in your email and endpoint tools if you have them.

Evidence: the register entry showing the data classes each tool is approved for, and any data loss prevention alerts reviewed.

Section 4. Human review of AI output

Policy wording: AI output must be checked by a competent person before it is sent to a client, published, used to make a decision about a person, or relied on for advice. The person who sends or uses the output is accountable for it, not the tool.

Control: For any workflow where AI drafts something that reaches a client, build the review into the workflow itself as an approval step that cannot be skipped, rather than relying on memory.

Evidence: the approval log showing who approved what, and when.

Section 5. Decisions about people

Policy wording: AI must not be used to make, or substantially make, decisions with legal or similarly significant effects on individuals, such as hiring, credit, pricing or eligibility, without a documented assessment approved by [AI owner] and, where personal data is involved, a data protection impact assessment.

Control: A short intake form for any new AI use case, which routes anything touching decisions about people to the AI owner.

Evidence: the completed form and the DPIA where one was required.

Section 6. Transparency

Policy wording: Where AI has materially produced content or analysis that a client relies on, we will be open about it if asked, and we will not present AI output as the personal work of a named expert who has not reviewed it.

Control: A standard line staff can use when clients ask how work was produced.

Evidence: the line in your client communication templates.

Section 7. Ownership and accountability

Policy wording: [Name, role] is the AI owner and is accountable for this policy, the Approved AI Tools Register and the handling of AI incidents. Line managers are responsible for their teams following it.

Control: The AI owner is written into the role description, not just this document.

Evidence: the role description and the owner's quarterly review notes.

Section 8. Incidents and stopping a tool

Policy wording: Anyone who believes client or company data has gone into an AI tool it should not have, or that AI output has caused harm, must report it to [AI owner] the same day. The AI owner can suspend any AI tool or workflow immediately while it is investigated.

Control: A named reporting route, and a documented way to switch off each approved tool or automated workflow, tested once before you need it.

Evidence: the incident log and the date the switch-off was last tested.

Section 9. Training

Policy wording: Everyone in scope will complete short training on this policy when they join and when it changes materially.

Control: Training tied to account access: no business AI account until the training is complete.

Evidence: completion records.

Section 10. Review

Policy wording: This policy is reviewed by the AI owner at least once a year and whenever we adopt a significant new AI tool, our regulator issues new guidance, or an incident shows a gap.

Control: A recurring calendar entry owned by the AI owner.

Evidence: the version history showing each review actually happened.

Do UK businesses legally need an AI policy?

There is no UK law that says every business must have a document called an AI policy. But UK GDPR, sector regulation and your client contracts already apply to how you use AI, and a policy is the simplest way to show you are meeting them.

The ICO publishes guidance on AI and data protection covering accountability, lawfulness, transparency and fairness when AI processes personal data, including what to consider in a data protection impact assessment. As at October 2026 the ICO notes that this guidance is under review following the Data (Use and Access) Act, so check it again before you finalise your policy. Under UK GDPR, a DPIA is required where processing is likely to result in a high risk to individuals, which many AI uses involving client data will be.

The stakes are not abstract. Under the ICO's fining guidance, the higher maximum fine is 17.5 million GBP or 4% of total worldwide annual turnover, whichever is higher. The ICO's standard maximum is 8.7 million GBP or 2% of turnover. Fines at that level are rare and reserved for serious failings, but the point stands: data you lose through an AI tool is still your data protection problem.

If you are FCA-regulated, the Consumer Duty requires you to evidence good customer outcomes, and you cannot evidence an outcome shaped by an AI tool nobody logged. Public bodies have their own reference point: the government's AI Playbook, published in February 2025, sets out 10 principles for using AI in government, including meaningful human control at the right stages and using AI securely. It is written for the civil service, but it is a useful sense check for any private-sector policy.

Should you ban ChatGPT and other AI tools at work?

A blanket ban rarely works, because it pushes AI use onto personal phones and accounts where you can see none of it. A short approved list with a fast way to request new tools gives you far more control than a ban.

Ethan Mollick, the Wharton professor who writes the One Useful Thing newsletter, called staff who quietly use AI at work "secret cyborgs". His argument was that bans make people hide their use because they do not want to get into trouble, and that firms should build targeted policies for specific types of use rather than blanket bans. The Microsoft figures above suggest that is exactly what has happened in many UK workplaces.

The risk of hidden use is now on analysts' radar too. Gartner predicts that by 2030 more than 40% of enterprises will experience security or compliance incidents linked to unauthorised shadow AI, according to its November 2025 analysis of generative AI blind spots. We have written separately about what shadow AI looks like inside a firm and how to make it auditable.

There are cases where a narrow ban is right. If a particular tool's terms allow it to train on your inputs and there is no business tier, banning that tool for client work is sensible. The difference is that you are banning a specific risk, and offering a sanctioned alternative, rather than banning AI.

How do you enforce an AI policy once it is written?

You enforce it by turning the riskiest rules into systems that make breaking them difficult and visible. Signatures and reminders do not enforce anything on their own.

Start with the two clauses that carry most of the exposure: approved tools and prohibited data. Give people a business account that is as easy to use as the consumer tool, and most of the shadow use disappears because the sanctioned route is now the convenient one. Then make the review step real for any AI output that reaches a client.

This is a common gap. ISACA found that 56% of respondents did not know how long it would take to halt an AI system after a security incident, and 39% did not know whether they had a documented process for shutting down or overriding AI systems at all. Section 8 of the template exists for exactly this reason: if you cannot switch something off, you do not control it.

In the systems KORIX builds, the review rule is not a sentence in a policy; it is part of the architecture. In our own lead intelligence system, no message can be sent without a human approving it. That is true by design, not by measurement: there is no send path that skips the approval step, and if one were ever added the claim would stop being true the same day. That is the standard to aim for with your highest-risk workflows. The rule and the control are the same thing.

For the controls that cannot be fully automated, keep the evidence light but regular. A quarterly ten-minute review by the AI owner of the tools register, the approval logs and any incidents is a sensible starting point for a firm of twenty to a hundred and fifty people. If you want the wider picture of how this fits into governance, our guide to what governed AI means in practice covers the full model, and the AI compliance checklist maps the main frameworks.

Does the EU AI Act change what goes in a UK AI policy?

It can, if you sell into the EU. The EU AI Act can apply to UK firms whose AI systems are placed on the EU market or whose AI output is used in the EU, as set out in Article 2 of the regulation.

For most UK service firms using AI internally for drafting, summarising and admin, the practical effect on this policy is small: the template already covers transparency, human review and decisions about people, which are the areas the Act cares most about. If you build AI products for EU customers, or use AI in areas the Act treats as high risk such as recruitment or credit, take specific advice, because the obligations and their timing are detailed and still being finalised.

How much does an AI policy cost to put in place?

The template costs nothing, and adapting it means filling in the bracketed parts and naming owners. The real cost is in the controls: business accounts for approved tools, a little IT configuration, and an owner's time each quarter.

For a typical firm of twenty to a hundred and fifty staff, the main recurring cost is business licences for the AI tools you approve, which you were probably going to need anyway, plus a few hours of the AI owner's time each quarter. If you already have managed devices and a business email platform with data loss prevention, much of the technical control is configuration rather than new spend.

The bigger cost appears when you want AI to do real work inside client-facing workflows, because that is where review steps, logging and a way to switch things off have to be built into the system rather than written into a document. That is the work KORIX does. Our 21-day governed AI pilot has a published range of 15,000 to 40,000 USD depending on scope, and if the system is not in production by Day 21 you do not pay the second half of the fee. You do not need a pilot to use this template; you need one only when you want a governed workflow built and running.

Who is this template not right for?

It is not the right fit if you build AI products for others, operate in a high-risk area under the EU AI Act, or need a policy that will stand up as a formal regulatory submission. In those cases use it as a starting checklist and get specialist advice.

It is also not ideal for a firm that has no intention of naming an owner or providing approved tools. A policy that bans consumer AI without offering a business alternative will be ignored, and an ignored policy is arguably worse than none, because it creates a written record that you knew about the risk. Be honest with yourself about this trade-off before you publish anything to staff.

And it is not a substitute for knowing where AI is already being used. If you do not yet know which tools your team relies on, start with a short anonymous survey or an honest team conversation; the register in Section 2 should describe reality, not an aspiration. Our article on whether you need a head of AI governance covers who should own this as you grow.

What should you do this week?

Name an AI owner, write down the tools your team actually uses, and decide which ones become approved business accounts. Those three steps make the rest of the template workable.

Monday: appoint the AI owner and give them this template.
Tuesday to Wednesday: list the AI tools in real use and decide approved, replaced or banned for each.
Thursday: adapt Sections 1 to 10, with a named control and evidence for each.
Friday: issue it, set up the business accounts, and put the first quarterly review in the calendar.

If one of your AI uses already touches clients and you want it running with the review step and audit trail built in rather than written down, book a free 30-minute consultation and we will tell you honestly whether it needs a pilot or just better configuration. For a view of what goes wrong when it is left ungoverned, see AI agent risks.

About this template: written by KORIX, the governed AI practice founded by Shishir Mishra. It reflects our reading of current UK guidance as at October 2026 and is not legal advice.

The bottom line: A policy is only as strong as the control behind each rule. Copy the template, then go clause by clause and name the control, the owner and the evidence. Any rule without all three is a wish. Start with the approved-tools list and the data you never paste in, because that is where most exposure sits.

What is governed AI? — AI that is observable, auditable, human-supervised, rollback-ready and owned by your team.
AI governance vs governed AI — the rulebook versus the system that enforces it at runtime.
AI compliance checklist (SOC 2, HIPAA, GDPR) — the nine controls to have in place before AI touches regulated work.
Shadow AI: making staff AI use safe — your team already uses AI for client work; how to make that use auditable.
Do you need a head of AI governance? — who should own AI decisions in your firm.

Shishir Mishra — Founder & Systems Architect (AI), KORIX. 19 years building enterprise software, now deploying governed AI agents across finance, healthcare, logistics, and real estate. KORIX deploys AI agents inside the tools your team already uses — not on top of yet another platform. Learn more about Shishir.

Originally published at korixinc.com — read with the full design + comments.

Tags: AI, AI Governance, Templates

SOC 2, CRA, NIS2: they all ask your cluster the same five questions

Fri, 23 Oct 2026 17:49:26 +0000

title: "SOC 2, CRA, NIS2: they all ask your cluster the same five questions"
published: true
description: "A working engineer's read of SOC 2 and the EU instruments that landed alongside it, and why the hard part is not the controls but the evidence that they ran."

tags: security, kubernetes, devops, compliance

In eleven days, on 11 September 2026, the reporting obligations of the EU Cyber Resilience Act start applying to anyone who puts a product with digital elements on the European market. Not the full regulation. Just the part where, if you find out an actively exploited vulnerability is in your product, you have 24 hours to tell ENISA about it.

I have watched a lot of engineering teams meet this class of deadline for the first time. It usually goes the same way. Somebody in sales gets a security questionnaire. Somebody in engineering gets forwarded the questionnaire. Three weeks later there is a shared folder called evidence-final-v3 with 200 screenshots in it, and nobody can tell you which screenshot answers which question.

I have spent the last several months building a tool whose entire job is that folder, so I read the instruments properly. This is what I found out. It is written for engineers, not for a compliance team, and I try to be specific about what the text says rather than what a vendor blog says it says.

Where SOC 2 came from, and why that still shapes it

SOC 2 exists because of a misuse.

In 1992 the AICPA published SAS 70, an auditing standard for service organisations. Its purpose was narrow: if you outsourced your payroll, your auditor needed some assurance that your payroll provider's internal controls did not corrupt your financial statements. It was an accounting instrument, for accountants, about financial reporting.

Then the industry outsourced everything else. By the mid-2000s companies were sending their customer data to service providers, and they wanted assurance about that, not about financial reporting. There was nothing designed for it, so they asked for the thing that existed. Vendors started waving SAS 70 reports around as proof they were secure. They were not proof of that. SAS 70 had no defined control set at all: the service organisation wrote its own control objectives, and the auditor tested against whatever had been written. Two SAS 70 reports could have nothing in common.

In 2010 the AICPA split the thing in half. Financial reporting controls stayed, renamed SOC 1 under SSAE 16 (SSAE 18 since 2017). The security question got its own report: SOC 2, with an actual defined set of criteria behind it.

That history is worth carrying, because SOC 2 still has SAS 70's shape in one important respect. It defines criteria, not controls. It tells you what has to be true. It does not tell you how. More on that in a moment, because it is the single most common misunderstanding.

Type I and Type II

Two report types, and the difference is most of the value.

Type I is a point in time. An auditor looks at your controls on one date and gives an opinion on whether they are suitably designed. It answers: do you have the right things in place?

Type II covers a period, typically 3 to 12 months, with 6 being the usual choice for a first report. The auditor gives an opinion on whether the controls were suitably designed and operated effectively throughout that period.

A Type I says you built the fence. A Type II says the fence was standing every day for six months.

Almost every buyer who asks for SOC 2 means Type II, or will mean it at renewal. And it matters enormously to how you should think about evidence, because "operated effectively throughout the period" is not a thing you can produce at the end. The auditor samples across the whole window. If your quarterly access review was supposed to run four times and it ran once, in the week before fieldwork, that is an exception in your report and everybody reading it can see it.

That property, that the evidence must have existed continuously rather than being assembled afterwards, is the one I would burn into a wall. It is what makes screenshot folders a bad answer.

The five criteria, and the four you probably do not need

SOC 2 is built on the Trust Services Criteria (AICPA TSP section 100, 2017, revised 2022). Five categories:

Security — the Common Criteria, CC1 to CC9. Mandatory. Every SOC 2 includes it.
Availability — is the system up when you said it would be
Confidentiality — is information designated confidential protected
Processing Integrity — is processing complete, valid, accurate, timely, authorised
Privacy — personal information handled per your notice

Only Security is required. You choose the rest, and you should choose as few as you can defend, because each one is more scope, more testing, more cost. Most infrastructure and SaaS companies do Security, or Security plus Availability. Add Confidentiality if your contracts talk about it. Processing Integrity is genuinely rare and mostly belongs to payments and payroll.

Inside the Common Criteria, the ones an engineer actually touches:

Criterion	Roughly
CC1–CC3	Governance, communication, risk assessment. Mostly organisational.
CC4	Monitoring: do you check your own controls are present and functioning?
CC5	Control activities.
CC6	Logical and physical access. Who can reach what, and how you keep the outside out.
CC7	System operations. Detecting vulnerabilities and configuration drift, spotting anomalies, handling incidents.
CC8	Change management. Nothing untested or unauthorised reaches production.
CC9	Risk mitigation, including vendor and third-party risk.

If you run containers on Kubernetes, most of your technical evidence lands in CC6, CC7 and CC8. CC6.8 is the one people miss: "the entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software." That is your image supply chain, stated in 2017 language.

SOC 2 does not tell you what to do

This is the part that catches teams out.

There is no SOC 2 control list. There is no "you must scan images" clause. The criteria are outcome statements, and you define the controls that meet them, and then the auditor tests the controls you defined. You write a control saying "all container images are scanned before deployment and images with critical vulnerabilities are blocked", and now you are on the hook to prove that happened every day of the period.

This cuts both ways. The freedom is real: you are not forced into somebody else's architecture. The trap is also real, and it is that a weak control, written vaguely, passes the audit while protecting nothing. "We use industry standard scanning tools" is a sentence that can be true while your cluster runs whatever anybody pushes.

The auditor is not there to tell you the control is weak. They are there to test whether it operated as described.

The other instruments, and their clocks

SOC 2 is voluntary and market-driven; you do it because a customer asked. Most of what arrived after it is not voluntary. Here is the landscape as it stands at the end of August 2026.

EU Cyber Resilience Act — Regulation (EU) 2024/2847. Applies to products with digital elements sold in the EU, which for most of us means the software itself. Three dates: conformity assessment bodies from 11 June 2026 (passed), vulnerability and incident reporting from 11 September 2026 (eleven days away), and the substantive obligations, including technical documentation and the SBOM requirement, from 11 December 2027. Annex I Part II point 1 is the SBOM clause: components documented in a commonly used machine-readable format, covering at least the top-level dependencies. You do not have to publish it. You do have to have it and hand it over when a market surveillance authority asks.

NIS2 — Directive (EU) 2022/2555. Applies to entities in essential and important sectors, and reaches software vendors indirectly, forcefully, through Article 21(2), which names supply chain security and requires covered entities to consider the security practices of their direct suppliers. That is why NIS2-derived questionnaires arrive at companies that are not themselves in scope. Being a supplier to somebody in scope is enough.

DORA — Regulation (EU) 2022/2554, in force since 17 January 2025 for EU financial entities and the ICT providers serving them. Chapter V Article 28 is the third-party risk chapter, and it has teeth in a way NIS2 does not, including audit rights written into contracts.

ISO/IEC 27001:2022 — certification rather than a report. Buyers outside the US often prefer it. Annex A control 8.8 (technical vulnerabilities), 8.25 through 8.31 (secure development, separation of environments) are the ones your pipeline touches.

NIST — SP 800-190 for container security specifically, SP 800-218 (SSDF) for secure development, SP 800-53 Rev. 5 for the full federal control catalogue. Not law unless you sell to the US government, but the language is precise and much of the rest of the world quotes it.

GDPR Article 32 — security of processing. Short, general, and still the clause that turns a container escape into a regulatory event if personal data was on the other side of it.

They are all asking the same five questions

Here is the thing I did not expect when I started reading these side by side. The instruments are written by different bodies, in different decades, for different legal systems, and underneath they converge hard.

CRA Annex I Part I (3)(g), on availability and resilience of essential functions, and SOC 2 A1.2 both turn on outages and what the system does when a component fails. CRA (3)(c) on access control and CC6.1 both turn on hardening and federated access. CRA (3)(k) on recording and monitoring activity and CC7.2 both turn on the audit trail. DORA Article 9's protection and prevention requirements land in the same place as CC6.8.

For a workload running in a cluster, strip away the citations and every one of them is asking:

What is running? An inventory. Not "what did we deploy", what is actually admitted right now.
Where did it come from? Provenance. A signature, an identifiable registry, a build you can point at.
What is wrong with it? Known vulnerabilities, against a database that was current at the time of the check.
Who allowed the exceptions? Because there are always exceptions. An unrecorded exception is indistinguishable from a control failure.
Can you prove all of the above for a period you did not choose in advance?

Question 5 is the one tools get wrong.

What good evidence looks like

Most compliance tooling is built to produce a dashboard. A dashboard tells you the state now. An auditor is not asking about now, they are asking about February.

Working backwards from what a Type II sampling exercise actually needs, evidence has to carry five properties:

A period, stated on the document. Not "generated today", but "covers 1 February to 31 July, and here is what happened in that window."

Provenance of the evidence itself. Who generated it, from which system, at what version. A compliance mapping is an interpretation, and interpretations change as you read a framework more carefully. Evidence that does not record which reading it used cannot be re-examined later.

Integrity. A PDF is a suggestion. Anybody can edit a PDF. If the document that goes to the auditor is not cryptographically bound to the bytes that were generated, then the strongest statement you can make about it is "someone in our company typed this."

Citation, not paraphrase. Every claim should name the clause it answers, quoted close to the instrument's own words. Auditors read the criterion, not your marketing vocabulary. If your report says "we are compliant with CC7.1" without restating what CC7.1 asks, you have made the reader do a lookup, and made yourself impossible to check.

Honest gaps. This is the one I care most about. A container security tool can evidence maybe a third of NIS2 Article 21. The rest is staff training, disclosure policies, reporting to a national CSIRT, business continuity. A report that quietly maps a feature list onto the other two thirds is worse than no report at all, because it tells an organisation a duty is discharged when nobody has done it. Anything that comes back all green is lying to you, and the lie is expensive precisely when it matters.

Why the admission controller is the right place to stand

For the Kubernetes-specific part of this: scanning in CI is necessary and insufficient.

CI scanning proves you scanned an image. It does not prove that only scanned images ran. Those are different claims and the second is the one CC6.8 asks for. Between the pipeline and the cluster there is a gap wide enough to drive a kubectl apply through: a manually applied manifest, a Helm chart from a vendor, a sidecar injected by a mesh, a latest tag that resolved to something different this morning than it did last week.

The admission webhook is the last point where the answer to "may this run" is still no. It is also the only point where a record of the decision is a record of what actually entered the cluster, rather than a record of intent. Every admission review is a dated, attributable event: this digest, this policy, admitted or refused, at this moment. That is the raw material a Type II sample is made of, and it accumulates whether or not anybody remembers to collect it.

That property, evidence that exists because the control ran and not because somebody prepared for an audit, is the whole point.

How we built this into Attestkeep

Attestkeep is a Kubernetes admission controller that scans images, verifies signatures and attestations, and enforces policy at admission. That part is not novel and I would not write a post about it. The part I want to describe is what happens after six months of it running.

You pick a period and a framework. It generates a report against eight of them: SOC 2, EU CRA + NIS2, DORA, NIST SP 800-190, SSDF, SP 800-53 Rev. 5, ISO 27001, and GDPR Article 32. Every requirement in the report carries its citation, the obligation restated close to the instrument's own words, a status, and a note written in the period's own numbers.

There are four statuses, and the fourth is the reason I am writing this section:

met — the control operates and the records show it operating
partial — it operates but something narrows what it proves: a permissive failure policy, audit-only mode, an exemption
gap — squarely within what this thing can enforce, and the records say it is not being enforced
outside_scope — a duty of the organisation, not a property of a cluster. Named rather than omitted, so the reader can see where the document's coverage ends.

Here is an unedited fragment from a real 30-day report generated against a demo cluster:

{
  "id": "CC4.1",
  "citation": "CC4.1",
  "title": "Evaluations to ascertain that controls are present and functioning",
  "asks": "The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.",
  "status": "met",
  "note": "the control's operation is measured continuously rather than sampled: 293 reviews, 31 admitted, 262 refused, and 3 windows in which it was not operating",
  "evidence": ["admission", "availability"]
}

and, from the same report, one that did not pass:

{
  "id": "CC6.6",
  "citation": "CC6.6",
  "status": "gap",
  "note": "no registry allow-list is in force, so an image may be pulled from any registry the node can reach",
  "evidence": ["control_statement.allowed_registries"]
}

The summary for that period was 3 met, 6 partial, 2 gap, 2 outside scope. That is a demo cluster with a loose policy, and the report says so. I would rather ship a tool that tells you that in August than one that tells you everything is fine and lets an auditor find it in February.

The evidence field is a pointer into the sections of the same document that carry the underlying numbers, so a reader can check the claim rather than accept the note.

Integrity. The report is signed with Ed25519 into a DSSE envelope carrying an in-toto Statement v1. The signature covers report.json and nothing else. The subject is the report's SHA-256, so the signature binds to the exact bytes, and any copy of those bytes can be checked against it.

What the auditor receives is a zip:

README.txt          what is signed, and three ways to check it
report.json         the evidence. these exact bytes are what is signed
attestation.json    DSSE envelope, in-toto Statement v1
certificate.jwt     the public half of the signing key, signed by us
<id>.pdf            a readable rendering. convenience only, carries no signature
<id>.attestkeep.json  all of the above in one file, for single-file verifiers

The README is always in English, whatever language the console is set to, because an auditor's file gets read in places you cannot predict. It states plainly that if the PDF and report.json ever disagree, report.json is the record and the PDF is wrong. Verification works three ways: a browser page that runs entirely client-side and uploads nothing, a Python script with no dependencies, or cosign if you already have it. The archive is byte-for-byte reproducible: the zip entry timestamps come from the report's own generation time rather than the clock, so two people downloading the same package get the same file.

And the scope statement, which is printed at the top of every SOC 2 report we produce:

It is evidence for an audit, not an audit: only a service auditor issues an opinion, and only the entity defines its own system boundary.

I put that there because I have seen what the alternative does to people. A tool cannot make you compliant. It can make the day the auditor asks a boring one.

What this does not do

Being straight about the limits, since I just spent 400 words demanding honest gaps from everybody else.

The compliance mappings have not been through legal or audit review. They are my careful reading of published texts, with citations included specifically so a professional can check my work rather than trust it. The NIST SP 800-190 citations were corrected once already, when I went back and compared them against the published guidance instead of my notes.

Nothing here binds a report to a trusted clock. generated_at is an assertion by the signer, not proof. If you need trusted timestamping, you need it from somewhere else, and the predicate says so in a comment rather than hiding it.

And the honest scope line applies to me too: one cluster's admission control answers part of SOC 2 and a smaller part of NIS2. It does not answer your access reviews, your onboarding, your incident response drills, or your vendor register.

If you take one thing

Whatever you use, and it does not have to be mine, make the evidence a byproduct of the control operating rather than a project you run before an audit. The frameworks converge on this even where their words differ. SOC 2 Type II wants the whole period. CRA wants technical documentation that was maintained, not assembled. DORA wants an audit right that is meaningful when exercised without notice.

Update (September 2026). Vinh Nguyen pointed out in the comments that questions 1 and 5 come apart exactly where this article admits they might: the admission ledger records honestly when the control was not operating, but nothing in it says what crossed during those windows — or what predates the install, or what walked in under failurePolicy: Ignore. Whatever did is still running long after the window closed, and a ledger of boundary crossings has no row for it.

He was right, so the control grew a second half. A periodic sweep now reads every running container's observed imageID — not the spec's image reference, which under a mutable tag still matches its original admission event while the bytes underneath have changed — and reconciles each digest against the admission ledger. A running digest with no allowed admission event behind it lands in the evidence package as its own population section, right next to the availability section it completes: the document that admitted the two questions come apart now stitches them back together. Policy decides what a finding does — recorded, announced, or the pod is stopped so its controller recreates it through the webhook, onto the ledger this time. The details, including the honest edges (out-of-scope namespaces, side-loaded images with no registry digest, truncated lists that say so), are in the comment thread below.

Evidence you can only produce by preparing for the question is not evidence that the control was working. It is evidence that you can prepare.

I build Attestkeep, a Kubernetes admission controller with compliance evidence built in. It is early. If you have been through a Type II with containers in scope and something above is wrong, I would genuinely like to hear it.

GPT-6 Astra: What to Decide Before You Switch It On

Wed, 21 Oct 2026 08:42:11 +0000

GPT-6 Astra is disabled by default in ChatGPT Business and Enterprise. An owner must turn it on. It is worth enabling for most teams, but three things changed that your AI policy probably does not cover: it is the first OpenAI model at the Critical cybersecurity threshold, its reasoning is materially harder to inspect than the model you use today, and OpenAI published both of those facts itself.

Who this guide is for

The person in a regulated firm who owns the decision: an IT director, a compliance lead, a managing partner. No machine learning knowledge required. If you are choosing a model for an engineering team, the benchmark round-ups will serve you better than this will.

Three facts, not the benchmark table

The capability is not in dispute. In OpenAI's own announcement Astra saturates three of the hardest public benchmarks: 98% on FrontierMath Tier 4, 99.9% on ARC-AGI-3 and 100% on ExploitBench, plus 72.6% on OSWorld 2.0 computer use. Those matter to an engineer choosing a model. They are not what a compliance officer, an IT director or a managing partner has to decide. These three are.

1. It is off until an admin enables it

In Business and Enterprise workspaces, Astra is disabled by default. An owner enables it for the whole workspace or for specific roles, and Early Model Access does not carry it over. Doing nothing is a valid choice. It should be a recorded one rather than an accident. Reported by 9to5Mac.

2. It is the first model rated Critical for cyber capability

OpenAI's Preparedness Framework reserves Critical for capabilities that open a new pathway to severe harm. Astra is the first model it has placed there, which requires safeguards during development rather than only at release. Reported by CNBC and The Hill.

3. It is harder to monitor, by OpenAI's own testing

Astra reasons using recurrent depth, which does not expose a readable chain of thought. OpenAI reported a substantial decrease in chain-of-thought monitorability against previous models. Reported by Gizmodo and TechRadar.

What you gain, and what you can no longer see

Until now, a reasoning model wrote down its working. That scratchpad was not a nicety. It was the practical mechanism by which a human, a red team, or an automated monitor could look at a model's output and ask how did it get here. It is the closest thing the industry has had to an audit trail on a model's judgement.

Astra reasons differently. Its recurrent-depth approach loops internally before producing an answer, and that loop is not rendered as readable text. The capability gain is real, and so is the trade-off: you are getting a better model and a less inspectable one in the same release.

That trade-off is worth naming plainly, because it decides who this guide is for. If a person reads every output before it does anything, the downside barely touches you. If you were planning to let the model act on its own against a customer record, this is not the release to start with, and we would tell you the same on a call.

98% — FrontierMath Tier 4, a benchmark OpenAI says Astra saturates. The capability is not in question. What changed is whether you can see how it got there.

OpenAI put it plainly in its own disclosure: Astra's written reasoning is harder to monitor than Sol's, the model it replaces. We looked for a figure putting a number on that gap and could not source one to OpenAI, so this piece does not carry one. The direction is what matters, and OpenAI has stated the direction itself. That is not a critic outside the building.

From inside the company that built it

"CoT monitoring is a core part of our misalignment safety strategy that has no good substitute now."

— Tomek Korbak, alignment researcher at OpenAI, quoted in TechRadar

"Progress in intelligence does not guarantee progress in alignment."

— Jakub Pachocki, chief scientist at OpenAI, quoted in Vellum

Both come from inside the company that built it, published alongside the release rather than dragged out of it. That candour is exactly what makes the model possible to plan around, and planning around it is the rest of this guide.

Critical is a word with a published definition

Critical is not marketing language. In OpenAI's Preparedness Framework it is a defined threshold, and the definition is worth reading slowly: a model reaches it if it can identify and develop functional zero-day exploits of all severity levels in many hardened real-world systems without human intervention, or devise and execute novel end-to-end cyberattack strategies against hardened targets given only a high-level goal.

The framework separates High capability, which amplifies an existing route to serious harm, from Critical, which opens a route that did not previously exist. Critical requires safeguards during development, regardless of whether the model is ever deployed. Astra is the first model OpenAI has placed in that band, and the cyber-sensitive capabilities are gated behind a restricted access programme OpenAI calls Daybreak, rather than shipped to everyone.

Two honest readings of that follow, and you should hold both. The first: OpenAI classified its own model at its most serious tier and restricted it, which is the framework doing its job in public. The second: your firm is now deciding whether to enable a tool its maker has described in those terms, and your AI policy was almost certainly written before that sentence existed.

Who should enable it, and who should wait

There is no universal answer here and anyone giving you one is selling something. The useful question is not "is Astra safe" but can we evidence what it did, and can we undo it. That splits cleanly by what the model is allowed to touch.

If the work is	Enable it?	Because
Drafting, research, summarising, internal analysis	Yes, with logging	A human reads the output before it does anything. Opaque reasoning matters far less when a person is the last step.
Coding and engineering work	Yes, in a reviewed pipeline	Code review is already your inspection layer. You are reviewing the artefact, not the reasoning, and that was always true.
Anything that writes to a system of record	Only with an audit trail and a reversal path	If you cannot read the reasoning, the log of actions becomes your only evidence. It has to be complete before you switch this on, not after.
Anything that touches a customer outcome unsupervised	Not yet	Under Consumer Duty and similar regimes you must be able to evidence why a customer was treated a certain way. "The model decided" is not evidence.
Security testing or offensive tooling	Separate decision entirely	These are the capabilities OpenAI gated behind Daybreak. Treat it as a procurement and legal question, not an IT toggle.

It is worth being precise about the standard we are applying, because "governed" gets used loosely. KORIX defines governed AI as a system whose every action is logged against a named accountable human, scoped to what it may touch, and reversible without a rebuild. Those three properties are what let a firm answer a regulator, an auditor or an angry client after the fact. None of them depend on being able to read the model's reasoning, which is precisely why they matter more now than they did last month.

That is also the honest limit of this guide. A more inspectable model would give you a fourth line of evidence on top of those three. Astra gives you a faster and more capable one instead. OpenAI's own system card is the place to read the detail if you want it first-hand rather than summarised.

Notice that the first two rows are a straightforward yes. The concern is not the model. It is the gap between what it can do unsupervised and what you can prove afterwards. That gap is exactly what governed AI exists to close, and it just got wider by default.

Five things to settle before you enable it

None of these require a project. They require a named person and an afternoon.

1. Name the owner. One person decides whether Astra is on, for which roles, and reviews that quarterly. If nobody owns the toggle, the answer to "who approved this" is nobody.

2. Check the toggle rather than assume it. Astra is off by default and Early Model Access does not carry over, so your workspace state may not be what you think. Look at it.

3. Decide what it may write to. Reading and drafting is one risk profile. Writing to your system of record is another. Put that line in writing before someone discovers it by accident.

4. Make the action log the audit trail. You can no longer lean on readable reasoning, so what the model did has to be logged completely, with timestamps and a named accountable human, in a system you already trust.

5. Write down the reversal path. For every action it can take, know how to undo it and who can. If an action cannot be undone, it should not be automated yet, whatever the model scores.

If your staff are already using AI outside sanctioned tools, settle that first. A model policy nobody follows is not a control, and shadow AI does not wait for a rollout plan.

What we are doing with it, and where we are not

KORIX is an OpenAI Select Partner, which is why we read a release like this closely and why our first instinct is to help clients adopt it rather than avoid it. It does not mean we speak for OpenAI: everything above is their published material and our own reading of it. We have also said publicly that roughly 60% of our production AI runs on OpenAI and the other 40% deliberately does not. That split has never been about loyalty. It is about which workloads we are willing to put behind a single vendor's judgement.

Astra has not changed that ratio and we are not going to pretend it did in the first week. We are using it where a human reads the output before anything happens, which is most of our engineering and research work, and the speed gain there is real. We are not putting it behind an unsupervised action on a client's system of record until we can evidence what it did as well as we could with the previous model. Not because we think it is dangerous, but because the honest answer to "show me why it did that" got harder this month, and that answer is the product we sell.

Questions we are actually getting

Is GPT-6 Astra safe to use in a regulated firm?

For drafting, research and analysis where a human reads the output before anything happens, yes, and it is a meaningful upgrade. For unsupervised actions that touch a customer outcome or write to your system of record, not until your action logging and reversal path are good enough to stand on their own. The change is not that the model became unsafe. It is that readable reasoning is no longer available as a second line of evidence.

Do we have to do anything, or does it just arrive?

You have to act. Astra is off by default in Business and Enterprise workspaces and an owner or admin must enable it, per role or for the whole workspace. Existing Early Model Access settings do not carry over.

What does the Critical cybersecurity rating mean in practice?

It is a defined threshold in OpenAI's Preparedness Framework, not a marketing term. It covers models that could find and build working zero-day exploits in hardened real systems without a human, or run novel end-to-end attacks from a high-level goal. It triggers safeguards during development, and OpenAI has gated the cyber-sensitive capabilities behind its Daybreak access programme rather than shipping them broadly.

What is recurrent depth and why does it matter to compliance?

It is a reasoning approach where the model loops internally before answering instead of writing out visible intermediate steps. It is faster and more capable. The compliance consequence is that the readable chain of thought, which teams and monitors used to inspect how a conclusion was reached, is largely gone. OpenAI's own testing reported a substantial decrease in chain-of-thought monitorability compared with previous models.

Should we switch our existing AI workflows over to it?

Not automatically. Move the workloads where a human is the last step and you will likely see a real speed gain. Leave anything running unsupervised against a system of record on whatever you have validated, until you have re-tested it and your logs capture enough to evidence the outcome without relying on the model explaining itself.

What does GPT-6 Astra cost?

API pricing has been reported at 10 US dollars per million input tokens and 50 per million output, with cached input lower and batch processing at half rate. For most firms the token cost is not the deciding factor. The cost that matters is the governance work around it. We publish our own range rather than quoting after a call: a governed build for one workflow runs Rs 5L-Rs 15L, delivered through a fixed-scope 21-day pilot. A single clean workflow sits toward the lower end; several systems, legacy data and heavy sign-off push it toward the top.

Is this just AI safety theatre?

A fair question and worth being blunt about. OpenAI classified its own model at its most serious tier, restricted the sensitive capabilities and published that its monitorability got worse. That is the opposite of theatre. What would be theatre is a vendor, including us, using the announcement to imply your business is in danger unless you buy something. Most firms should enable it for supervised work and change very little else.

The bottom line

GPT-6 Astra is a genuine capability step and most firms should enable it for work where a person reads the output. The decision that deserves an hour of your time is narrower: anywhere the model acts without a human in the loop, your action log has just become the only evidence you have.

If that log is complete, timestamped, and owned by a named person, this release is good news for you. If it is not, the right move is not to block the model. It is to fix the log first, then switch it on.

Originally published at korixinc.com.

Two Complaints in Two Years: New York City's AI Hiring Law Made a Record Nobody Can Read

Thu, 24 Sep 2026 05:51:26 +0000

The state Comptroller found two complaints in twenty-four months. Cornell's team found 14 audit reports among 267 employers. Both measurements hit the same wall: a disclosure rule whose scope is set by the discloser produces a record that cannot tell silence from exemption.

Between July 2023 and June 2025, New York City's Department of Consumer and Worker Protection received two complaints about employers using automated hiring tools without the bias audit the city requires. Two, in twenty-four months. The count comes from the New York State Comptroller, whose auditors spent that window's records deciding whether the department had "designed and implemented an effective system to enforce compliance with Local Law 144." Their answer, published on December 2, 2025, was that the department's complaint process "is ineffective in ensuring that all complaints related to non-compliance with LL144 are routed to DCWP."

The auditors then did the thing a complaint count cannot do for itself: they went and looked. The department had surveyed 32 companies about their use of these tools and found one non-compliance issue. The auditors examined the same 32 companies and found 17 potential instances. And the department's own words for the limit it works under, quoted in the audit, are these: "If an employer does not take these steps, it's difficult to identify non-compliance."

That sentence is the subject of this piece. It sounds like an admission of under-resourcing. It is a description of the law's design, and it means the near-empty record the city has built cannot be read as good news or as bad.

What the law asked for

Local Law 144 of 2021 prohibits employers and employment agencies from using an automated employment decision tool unless the tool "has been subject to a bias audit within one year of the use of the tool, information about the bias audit is publicly available, and certain notices have been provided to employees or job candidates." Enforcement began on July 5, 2023. The penalties are small per unit and multiply by time: not more than $500 for a first violation, $500 to $1,500 for each subsequent one, and each day a tool is used in violation counts as a separate violation.

Read the requirement again and notice what kind of law it is. It does not tell employers to do something to candidates. It tells them to publish something about themselves. The audit summary must be public. The notice must be given. Compliance leaves a paper trail by definition, which means the law creates its own public record, and anyone with a browser can go and count what is in it.

The first count, 2023

Somebody did. In the autumn of 2023 a team from Cornell's Citizens and Technology Lab, Data & Society and Consumer Reports recruited 155 student investigators and sent them through employer career sites between October 24 and November 9, modelling what a job seeker would see. The paper that came out of it, "Null Compliance: NYC Local Law 144 and the Challenges of Algorithm Accountability," presented at FAccT 2024, reports in its section 6.1: "Among 267 employers posting open jobs in NYC, we found 14 audit reports and 12 transparency notices."

Fourteen of 267 is 5.2 percent. Twelve of 267 is 4.5 percent. The paper's own abstract gives a different figure, 18 audit reports among 391 employers; that is the full set of employers the students recorded rather than the subset with live New York postings, and it works out to 4.6 percent. The two figures are not rival estimates of one quantity, and I am not going to average them. Keep the denominators attached. That habit is going to matter in a moment.

So a few months after enforcement began, roughly one employer in twenty had put anything in it. The obvious reading is that nineteen in twenty were breaking the law. The authors refuse that reading, and the refusal is their contribution.

Null compliance is not non-compliance

The paper names the state it found: "Null compliance describes a state in which the absence of evidence of compliance cannot be ascertained as non-compliance because the investigator lacks the information to determine if the regulated party's actions or products are in scope of the regulation."

The mechanism sits in the law's trigger. Local Law 144 covers tools that substantially assist or replace the human decision. Whether a given piece of software does that is not a property of the software. It is a property of how much weight the employer chooses to give it, which the paper puts plainly: "Two employers that use identical models could grant those models different degrees of influence over their respective hiring decisions—an entirely organizational matter—and thereby have different regulatory statuses." The regulated party decides whether it is in the population.

The survey the researchers ran beside the site walk shows what that decision looks like from the inside. Of the 26 firms that answered, 23 said the law did not apply to them. Eighty-eight percent of a small, self-selected group, so not a rate to build on, but a clean illustration. An employer that posts nothing may be using no such tool, or using one it has decided does not substantially assist anyone, or using one it should have audited and did not. From the career page all three look identical. The absence of a disclosure is the same absence in every case.

So the 5.2 percent is not a compliance rate. It is the share of employers who both fell inside the law by their own reckoning and did what it asked. Nobody outside those employers knows the size of the first group. The denominator that would make the number readable is the one number nobody holds.

The second count, 2025, by the state

Two years later the Comptroller's office measured the same record from the other side, the enforcer's, and hit the same wall. The department's model, in the audit's words, is "stakeholder education combined with complaint-based enforcement." A complaint-based design asks candidates to report a violation. The violation here is an absence: an audit summary that was never posted, a notice that was never given. A candidate who was screened by an unaudited tool and never told is, by construction, a person who does not know it happened. The two complaints in two years are not a measure of how often the law was broken. They are closer to a count of how often a violation of this kind is visible to the person it happened to.

That is why the department's sentence about difficulty is not a resourcing complaint. If an employer does not post, the employer is either outside the law or breaking it, and from the outside there is no third thing to look at. The auditors' 17 potential instances against the department's one, in the same 32 companies, is the only place in either measurement where a second, closer look changed the count. It took the state's access to get it, and it is still labelled potential.

Put the two measurements side by side. Researchers walking the public record in 2023 found it nearly empty and said they could not tell why. State auditors reading the enforcement record in 2025 found it nearly empty and, in effect, said the same. Neither found that the law is working. Neither found that it is failing. Both found that the instrument they were holding could not answer the question, and it is the same instrument: a record whose population is defined by the people in it.

What would make the zero legible

None of this says employers are breaking the law, and I want to be exact about that, because converting "null compliance" into "non-compliance" is the error the paper exists to name. It also does not say the law failed; the state audit examined the department's enforcement system and addressed its six recommendations to the department, not to the statute. And I have counted nothing myself. The counts are the researchers' and the auditors'. The only arithmetic here is division, and the script that does it ships beside this essay with each figure's locator.

What the two measurements do establish is a condition. A disclosure rule whose scope is decided by the party disclosing produces a record that cannot distinguish silence from exemption. Any count taken from that record, high or low, inherits the ambiguity. Two complaints, fourteen audits, one issue found, seventeen suspected: every one of those numbers has the same missing denominator, which is the number of employers who were actually inside the law.

A zero becomes readable when someone other than the regulated party defines the population. A register of employers using such tools, or a duty to declare use rather than only to audit it, would turn the next walk through the career sites into a measurement. Whether New York should want either is a policy question this piece is not placed to settle. What can be said is narrower and holds either way. The city built a public record to find out whether hiring software was being checked for bias. Two years and two instruments in, the record's clearest finding is that it cannot be read.

Reproduction script, published with this piece and runnable with no API key or network access: rates_c5500.py. Every percentage and ratio above is computed there from the published counts, each row carrying its source locator, and the 14-of-267 and 18-of-391 figures are kept as separate populations on purpose.

Sources: Lucas Wright, Roxana Mika Muenster, Briana Vecchione, Tianyao Qu, Pika (Senhuang) Cai, Alan Smith, Jacob Metcalf and J. Nathan Matias, "Null Compliance: NYC Local Law 144 and the Challenges of Algorithm Accountability," FAccT 2024, arXiv:2406.01399, DOI 10.1145/3630106.3658998, sections 2.2, 3, 5.1 and 6.1; Office of the New York State Comptroller, "Enforcement of Local Law 144 – Automated Employment Decision Tools," audit published December 2, 2025, covering July 2023 through June 2025; NYC Department of Consumer and Worker Protection, "Automated Employment Decision Tools" (the requirement and the July 5, 2023 enforcement date); New York City Administrative Code § 20-872 (the penalty schedule); Citizens and Technology Lab, "Studying How Employers Comply with NYC's New Hiring Algorithm Law" (the 18-of-391 figure, cited as the write-up's own).

A disclosure record is only as readable as its population

Local Law 144 asks employers to publish something about themselves, then lets each employer

    decide whether it is covered. The result is a record where an absence proves nothing. The same
    shape shows up wherever an agent's behaviour is self-reported: a claim with no population
    behind it. Chain of Consciousness keeps a record of what an agent actually did, over traffic
    someone else can check, so a rate you publish carries the denominator it was measured over.

pip install chain-of-consciousness
npm install chain-of-consciousness

Or start without installing anything: Hosted Chain of Consciousness.

← Back to blog

The crucial policy pattern

Tue, 15 Sep 2026 06:56:15 +0000

When you author policies in Rego to be evaluated by Open Policy Agent (OPA), there are a whole heap of patterns you can use to make policies correct, safe, predictable, and maintainable. You could write a whole book on this topic, and along with John Bristowe and Matt Allford, I have!

Today, though, I want to share the most crucial pattern in the whole Rego realm. The allow/deny pattern.

Using a policy engine like OPA means you are concentrating your highest-risk code in one place. In fact, that's the idea. Instead of implementing policies in many different languages and with many different execution environments you bet on Rego and OPA so you can write policies in a dedicated language and with an evaluation engine singularly purposed to this speciality.

With all this superbly important code in one place, it becomes vital to increase your discipline. No more "we'll add tests later" or "we can make it more readable next time we change it". This is the code that's making all the decisions, so you need it to be correct all the time.

The allow/deny pattern

It's time to meet the allow/deny pattern. This is the shape policies ought to take, even if they're simple. When you start a new policy that's going to decide if something is allowed, start with the first few lines of this file, then add your own partial set rules to collect reasons to say no.

package rental

default allow := false

# Only allow if we found zero reasons to deny
allow if {
  count(deny) == 0
}

# Collect reasons to deny
deny contains msg if {
  not input.member.membership.active
  msg := "membership is not active"
}

deny contains msg if {
  input.member.membership.fees_outstanding
  msg := sprintf("outstanding late fees of £%.2f", [input.member.late_fees])
}

deny contains msg if {
  input.member.age < to_number(input.film.rating)
  input.member.membership.tier != "premier"
  msg := sprintf("member is %v, film requires age %v (or premier tier)", [input.member.age, input.film.rating])
}

This works by first saying no: default allow := false to make sure the default is safe. We then describe the only condition that will change this to a yes: allow if { count(deny) == 0 }, which means allow if we found zero reasons to reject the request.

With this safety net in place, you add one or more partial set rules to collect reasons to say no, like this one that says you have to have an active membership.

deny contains msg if {
  not input.member.membership.active
  msg := "membership is not active"
}

OPA evaluates all these rules and collects up rejection reasons. If you get denied, you have a set of reasons to explain why. Otherwise, you meet the condition for saying yes.

Crucial but not sufficient

This shape is such a solid approach, you should use it most of the time. You should keep in mind there are other potential problems that can be caused by missing data, invalid schemas, or lack of tests. You need to account for all the reasons policies can go wrong, but the allow/deny pattern works alongside the other methods of writing correct, safe, predictable, and maintainable policies.

Those other necessary practices are covered in Exploring Rego, which will be landing in bookshops near you soon.

AI Chatbot Security and Governance: What Every Business Needs Before Launch

Tue, 08 Sep 2026 09:54:11 +0000

Security review is not the exciting part of an AI chatbot project. It is often the part that gets rushed under deadline pressure, and it is exactly the part that should never be rushed.

A single governance gap can turn a promising deployment into a costly incident. Here is what needs to be in place before anything goes live.

Security Controls and Access Permissions

Every chatbot needs clearly defined access permissions determining exactly what data and systems it can reach. This should follow the principle of least privilege, granting only what a specific use case genuinely requires.

Strong security controls also include monitoring for unusual activity, since a compromised chatbot with broad access represents a serious exposure point.

Data Boundaries: What the Bot Should Never Touch

Not all data belongs inside a chatbot's reach, even if it would technically be convenient. AI chatbot development should define clear data boundaries before launch to prevent accidental exposure later.

This typically means restricting access to certain financial records, personal health information, or any data outside the specific scope of the chatbot's approved use case.

Guardrails, Input Filters, and Output Policies

Guardrails work at multiple points in the conversation. Input filters screen what customers can send to the system, while output policies control what the chatbot is allowed to say back.

Together these prevent the system from being manipulated into revealing sensitive information or producing responses the business never approved.

Topic Boundaries and Refusal Thresholds

A well governed chatbot knows what it should not discuss. Topic boundaries define these limits clearly, and refusal thresholds determine how the system responds when a request falls outside them.

Getting this right avoids two opposite failure modes: a chatbot that refuses too aggressively and frustrates legitimate customers, or one that answers questions it was never authorized to touch.

Escalation Thresholds and Human Handoffs

Governance also means knowing when to step back. Escalation thresholds define the point at which a conversation should move to a human, particularly for regulated interactions or emotionally charged situations.

Well designed human handoffs preserve context so the transition feels seamless rather than jarring for the customer.

Audit Controls and Ongoing Monitoring

Governance does not end at launch. Audit controls create a record of what the chatbot said and did, which matters enormously during a compliance review or a customer dispute.

Ongoing monitoring catches drift in model performance or unexpected behavior before it escalates into a larger issue.

Compliance Basics: Privacy and ISO 27001

Depending on the industry, additional compliance requirements may apply. Privacy regulations govern how customer data can be collected, stored, and used within the chatbot system.

Many organizations also look to frameworks like ISO 27001 as a benchmark for information security management, particularly when working with a vendor rather than building entirely in house.

A Pre Launch Governance Checklist

Before a chatbot reaches real customers, this list is worth reviewing carefully.

Confirm access permissions follow least privilege across every integration
Test guardrails against deliberate attempts to bypass them
Verify escalation thresholds trigger correctly for sensitive topics
Confirm audit logs capture full conversation history
Review compliance requirements specific to your industry and region
Assign clear internal ownership for ongoing monitoring after launch

Why This Stage Protects the Whole Investment

Skipping governance work does not remove the risk, it simply delays when that risk becomes visible. A single public incident involving leaked data or an inappropriate response can undo months of positive customer sentiment built through the rest of the deployment.

Treating security and governance as core to the build, not an afterthought layered on at the end, is what separates deployments that hold up under scrutiny from ones that eventually make headlines for the wrong reasons.

Frequently Asked Questions

What is the principle of least privilege in this context? It means the chatbot only accesses the specific data and systems required for its defined use case, nothing broader.

How are guardrails different from data boundaries? Data boundaries define what the system can access. Guardrails define what it is allowed to say, even with access to certain data.

Why do audit controls matter after launch? They provide a verifiable record for compliance reviews and customer disputes, which becomes critical if an issue is ever challenged.

Does every industry need the same level of governance? No, but every industry needs some baseline. Regulated sectors like financial services and healthcare require considerably more rigor.

Who should own ongoing monitoring internally? This should be assigned explicitly rather than assumed, ideally to a team with both technical and compliance visibility.

Building on a Secure Foundation

Governance is not a constraint on innovation, it is what allows a chatbot to operate at scale without becoming a liability. The next post in this series looks at the data and knowledge foundation these systems depend on, which governance ultimately exists to protect.

80% of Companies Are Already Out of Step With the AI Act and Don't Know It

Wed, 02 Sep 2026 11:41:02 +0000

The tool worked. That was never the problem. A business manager had specced it with AI, straight from the business need, and the result did what he asked: it ran, it produced output, it looked finished. What it did not have was a single log line. No trace of why it produced a given answer. Nothing that could explain, later, a bad call made on real employee data. Nobody had asked for any of that, so the AI built none of it.

That absence is the gap nobody priced in. Scaled across a company and pointed at the wrong category of system, it puts you out of step with the EU AI Act without a single person acting in bad faith.

The AI Act assumes an engineering floor you may not have built

Here is the collision worth sitting with. The AI Act (Regulation (EU) 2024/1689) does not ask high-risk system operators to start testing their AI. It assumes they already do. Read the high-risk obligations and you will notice they are written on top of an engineering discipline that is taken for granted. Article 12 and Article 19 require automatic record-keeping and logging, with logs retained at least six months. Annex IV and Article 11 define what the technical documentation must contain; Article 18 requires keeping it at the disposal of authorities for ten years after the system is placed on the market. Article 14 requires human oversight designed in, with real intervention and stop capability, and it clearly calls out automation bias — the tendency to over-trust a machine's output — which tells you the drafters understood exactly how people behave around confident machines. Article 15 requires testing for accuracy, robustness, and resistance to adversarial manipulation.

Every one of those clauses assumes a working baseline: that you log what your systems do, that you test them against errors, that a human can see inside the decision and pull the lever when it goes wrong. The Act regulates on top of that floor. It does not build the floor for you.

Now hold that next to the data. The ServiceNow and ThoughtLab Enterprise AI Maturity Index for 2026 surveyed 4,500 executives and 2,000 employees across 19 countries and 12 industries. The number that matters: only 20% of organizations have implemented AI testing, auditing, and risk-assessment processes. Read that the way an engineer reads a red alert on a dashboard. Four out of five organizations have not built the discipline the high-risk regime stands on.

So the inference — and I want to be precise that it is an inference, not a directly measured compliance figure — is that roughly 80% of companies are structurally out of step with what the Act assumes, for any system that falls in the high-risk tier. The obligations exist on paper; the engineering they depend on does not.

Almost everything written about the AI Act treats it as a legal question: what does "high-risk" mean, what exactly does Article 14 require. Read it that way and the hard part is understanding the text — as if the logging, testing, and oversight would somehow build themselves once the reading is done. They do not build themselves. The Act is an engineering problem wearing legal language, and the harder question is whether the infrastructure it takes for granted — the logging, the testing, the oversight — exists in your organization at all. For most companies the honest answer is no, and they have never checked.

Scope this before you panic

The alarm only applies to a specific subset of systems, and saying so is the difference between analysis and fear-mongering. The Act tiers systems by risk. Most internal tools — the meeting summarizer, the draft-email assistant, the thing that reformats your reports — sit in the minimal-risk tier and carry none of these obligations. You can run those with a clear conscience and a thin paper trail.

The obligations attach to the high-risk tier, defined largely by Annex III: systems used in employment and worker management, access to essential services, credit scoring, critical infrastructure, biometric categorization, and a handful of others. A tool that screens job candidates, ranks employees, or gates someone's access to a service is in a different legal universe than one that summarizes a PDF.

So the first move is not legal. It is classification. You cannot assess your exposure until you know which of your systems are in scope, and in my experience companies have done this for zero of them. They know the AI Act exists. But they have not mapped their own deployments against it. The business manager with the AI-specced tool could not have told you which tier it fell in, because the question never came up, and depending on what that tool actually decides, the answer changes everything about what he owed under the law.

The reason capability outran the floor

The same maturity report explains how we got here. 59% of organizations are past piloting agentic AI, but only 9% have working autonomous multistep workflows. Capability is being deployed far faster than the governance layer beneath it. Only 16% have replaced fragmented legacy systems with an integrated platform; 41% still cite siloed data as a blocker. You cannot log and audit a decision cleanly when the data feeding it lives in six disconnected systems and the workflow stitching them together is held up with visual no-code duct tape.

I have lived the small version of this, spending months building AI automation pipelines in visual tools. They produced output. But when a node failed silently, I had no clean trace of what happened or why, and debugging meant clicking through visual steps trying to find which one died. I eventually rewrote the core of it as proper code, and what changed was not speed. I could finally see inside it. Now imagine that same opacity at a corporate level sitting under a system that decides who gets a loan or who keeps a job. That is the engineering gap the Act assumes you closed before it ever showed up.

There is a cultural tell in the data too. 57% of employees think leadership is not keeping up with fast-changing trends. That is what the governance gap feels like from below: the people closest to the work can sense that the controls are not there, even when the official version says they are.

What this actually requires of you

Stop treating this as a question of whether you have read the regulation correctly. The exposure for anything you run in the high-risk tier comes down to one thing: whether the testing, logging, and oversight discipline — the one the entire regime takes for granted — actually exists under your systems. If it does not, you are not one clause away from compliance. You are one engineering layer away, and that layer takes months to build and tune, not an afternoon with a lawyer.

The work is two concrete steps, in order. First, classify your AI systems by tier so you know which ones carry high-risk obligations and which ones you can leave alone. Most of your tools will fall out of scope, and that is the point. You want to spend your effort where the law actually bites. Second, for the systems that remain, check whether the assumed baseline is there: automatic logging you retain, documentation you can produce, testing against accuracy and adversarial failure, and a human who can both see the decision and stop it.

When that human can pull the stop lever in time and understands what they are overriding, you have oversight. When the data feeding the decision lives across four disconnected systems with no trace of what changed, you have a documentation requirement you cannot satisfy and an audit you would fail. A structured workflow audit is one way to surface exactly where those traces break down.

Most companies have done neither step. They have not classified their systems, and they have not audited the foundation under the ones that matter. Start with the first. Pull a list of every AI-assisted system that touches employment, access, credit, or essential services, and ask one question of each: if a regulator asked us to show six months of logs and explain a single decision, could we. The systems where the answer is no are your real exposure — and that one hour of asking will tell you more than another month of reading the Act.

Originally published at unlockedconsulting.ai.

The Compliance Ratchet

Wed, 19 Aug 2026 09:00:00 +0000

In this episode of Continuous Delivery Office Hours, Steve Fenton is joined by Octopus Deploy founder Paul Stovell to explore the hidden bottleneck in the AI productivity conversation that nobody is talking about: compliance and risk tolerance.

Everyone wants code written faster, so they are turning to AI to make it happen. But the constraint is never coding speed, it's the organization's appetite for change... and that means things are about to get more painful.

The physics of organizations means faster change generation will create an equal and opposite reaction in risk-averse environments that introduces irreversible road blocks.

Listen to find out more about:

Why developer velocity was never the real bottleneck in regulated organizations
The compliance ratchet: why risk requirements only ever go up, never down
How AI could be applied to risk assessment rather than just code generation
Why fragmented on-machine AI agents are creating a UX coherence crisis
The product velocity bullseye and why direction matters as much as speed
How to avoid inviting regulation by rolling out AI responsibly

How the EU AI Act's Risk Tiers Actually Classify Your AI System

Fri, 31 Jul 2026 14:32:59 +0000

The EU AI Act isn't just incoming regulation - it classifies AI systems by risk and sorts what you're required to build, document, and prove before you ship.

The Risk Tier System and What It Requires

The Act sorts AI systems into four risk tiers: unacceptable risk (banned outright), high risk, limited risk, and minimal risk. Most teams building internal tools, chatbots, or recommendation features land in the limited or minimal risk buckets - which carry light obligations, mostly around transparency (telling users they're interacting with AI).

The tier that demands real engineering attention is high risk. Systems in this category include AI used in hiring, credit scoring, education assessment, critical infrastructure, and healthcare triage. If your product touches any of those domains, you're looking at mandatory conformity assessments, human oversight mechanisms, detailed technical documentation, logging of system outputs, and data governance requirements before you can legally deploy in the EU.

High-risk systems must be built to support auditability from the start - not retrofitted. That means logging inputs and outputs with enough context to reconstruct decisions, building in a kill switch or human override, and maintaining a risk register that maps each failure mode to a mitigation.

Real Example

Here's a minimal logging pattern for a high-risk AI decision endpoint - the kind of audit trail the Act expects to exist:

import uuid, datetime, json

def log_ai_decision(input_data, model_output, model_id):
 record = {
 "decision_id": str(uuid.uuid4()),
 "timestamp": datetime.datetime.utcnow().isoformat(),
 "model_id": model_id,
 "input_hash": hash(json.dumps(input_data, sort_keys=True)),
 "output": model_output,
 "human_reviewed": False,
 }
 # Write to append-only store (e.g., S3, BigQuery, audit DB)
 audit_log.append(record)
 return record

This isn't compliance theatre - it's the minimum scaffold you need to answer "what did your system decide, and why, on date X?" - a question regulators can ask. The human_reviewed flag signals where oversight happened and where it didn't.

For non-technical roles: think of this as a receipt system for every AI decision your product makes. Without it, you can't demonstrate accountability after the fact.

Key Takeaways

The EU AI Act's impact on your team depends almost entirely on which risk tier your use case falls into - mapping that early saves rework later.
High-risk AI systems require audit logging, human override mechanisms, and pre-deployment conformity assessments - these aren't add-ons, they're architectural requirements.
Products in limited or minimal risk tiers mostly just need to disclose that they're AI-powered - a much lower bar, but still a legal one.

If you're currently building an AI feature for a regulated domain, what's your team's current approach to logging model decisions in a way that could survive a compliance review?

Sources referenced: OpenAI Blog - Advancing responsible AI across Europe; EU AI Act official text summary (European Parliament)

Change Approvals

Wed, 29 Jul 2026 09:00:00 +0000

In this episode of Continuous Delivery Office Hours, Tony Kelly, Bob Walker, and Steve Fenton discuss the purpose and common pitfalls of software change approvals. They argue that strict, manual change approval processes are often just a reflex to past organizational trauma and an attempt to have "humans on the hook" to blame, rather than a valuable safety measure.

Relying on excessive bureaucracy, like formal monthly review boards or demanding multiple manual sign-offs, significantly reduces deployment throughput and, according to DORA research, actually makes systems less stable. Instead, the experts advocate automating the vast majority of checks, like tests, linting, and scanning for dangerous database commands, so that human reviewers step in only to evaluate a filtered subset of complex or high-risk changes.

Effective change management requires small review requests and daily co-ordination rather than formal change approvals.

Listen to find out more about:

Change approval processes are often based on past organizational trauma
Most checks should be automated
Excessive manual approvals wreck throughput and reduce stability
If you review pull requests, they should be small

Your AI PoC Works. Here's Why It Still Won't Reach Production

Tue, 28 Jul 2026 09:32:35 +0000

The demo went well. The model answered correctly, the stakeholders nodded, someone said "let's get this into production." That was six months ago. The PoC still runs, the roadmap still lists it, and it is no closer to shipping than it was on demo day.

If you build AI systems in a bank, an insurer, or any regulated company, you have probably watched this happen. The uncomfortable part: the PoC was never blocked by a bug. It was blocked by a line nobody drew.

The PoC was built on the wrong side of a line that did not exist yet

A typical proof of concept calls a hosted frontier model API. That is the right choice for a PoC: best capability, zero infrastructure, an afternoon to integrate. With synthetic or scrubbed data, nobody objects.

Production data is a different animal. The first review meeting asks questions the architecture cannot answer:

Which data classes does this workload send out, and who approved that list?
Where does inference happen? A query routed to a model hosted abroad has left the jurisdiction even when the database stayed in Frankfurt.
Where is the audit evidence, and can the vendor's log retention satisfy our supervisor?
Whose name is on this system when the auditor asks? Under Article 26 of the EU AI Act, operator duties stay with your company no matter what the vendor contract says.

None of these are model-quality questions. The model is fine. The architecture has no place to put the answers.

The retrofit trap

The instinct is to patch: add a redaction layer, move logs, amend the vendor contract, write a policy document. Each patch triggers the next review. Contracts get re-papered. Data flows get re-architected. Sign-offs get reopened. Every new use case renegotiates its own boundary from scratch, and your backlog queues behind one compliance team.

No project gets rejected in this loop. It just never clears. That is why the PoC is still "in review" six months later.

What the teams that ship do differently

The regulated teams I see reaching production all made the same move: they drew the compliance boundary before they committed to an architecture.

The pattern has three parts:

Classify data, not use cases. A short list of data classes that may cross to an external service, and a list that never does. Customer PII and scoring features stay in; public and cleared data may go out.
One gateway, one routing rule. Every model call goes through a single point that routes by data class. Regulated data goes to models running inside your jurisdiction on infrastructure you control; open-weight models cover most narrow workloads (classification, extraction, summarization) well. Everything cleared goes to the frontier API and gets the best capability per euro.
Evidence inside the boundary. Audit logs, routing decisions, and the data-flow diagram live on your side of the line, signed by one named owner.

With the boundary in place, "can we ship this?" becomes a routing question instead of a six-month negotiation. The auditor gets one line to test instead of forty integrations to untangle.

What to do with the PoC you have

You do not have to throw it away. Three steps:

Write the data-class list for the workload the PoC actually serves, and get compliance to sign it. This is days, not months, because it is one page.
Put a gateway in front of the model call, even a thin one. Route by data class from day one.
Move only the regulated portion inside the boundary. Keep the frontier API for everything cleared. Most PoCs split cleanly once the classification exists.

The PoC that reaches production is rarely the most impressive one. It is the one whose data flows survive the first review meeting.

I help teams in regulated industries take AI prototypes into governed production workflows. The compliance readiness checklist I run before any architecture review is at renezander.com/gdpr-checklist.

The AI Agent Compliance Checklist 28 Items That Unblock Enterprise Deals

Sun, 28 Jun 2026 15:23:22 +0000

If you're building AI agents and trying to sell into enterprise, you've probably hit the wall: the 40-page security questionnaire that asks about logging, access control, data residency, and adversarial testing - none of which you thought about while building the product.

I have compiled the 28 items that come up in nearly every enterprise security review, mapped to the frameworks that drive them: EU AI Act, SOC 2 Type II, ISO 42001, and NIST AI RMF.

The short version

Logging & audit trail

Log every prompt, response, and tool call with timestamps
Capture the full decision chain, not just input/output
Include threat detection metadata in every log entry
Retain for 6+ months (EU AI Act Article 12 minimum)
Tamper-evident storage (append-only, checksums, or WORM)
Log all admin actions (key creation, permission changes, config updates)

Access control

Auth on every endpoint, including dev environments
Role-based access - read-only users should not trigger destructive tool calls
Scope API keys to specific capabilities
Rotate credentials on a defined schedule
Track and alert on authentication failures

Data handling

Classify what data categories flow through your agent
Don't persist sensitive data beyond the session without documented need
Scan agent outputs for secret leakage (AWS keys, JWTs, connection strings)
Document your data processing pipeline and third-party processors
Implement data residency controls for EU customers

Security testing

Run adversarial testing before every release. Secra Simulate fires 64 attacks across 10 categories in 60 seconds - free, no signup for your first scan
Document testing methodology and results (auditors want evidence, not assertions)
Maintain a vulnerability disclosure process
Track and patch dependencies - keep a software bill of materials
Test tool/MCP integrations as separate attack surfaces

Runtime protection

Deploy input scanning on every user message
Monitor for anomalous usage patterns with alerts, not just dashboards
Rate limit all public endpoints (per user, per key, per endpoint)
Have a kill switch that gets you to zero traffic in under 60 seconds

Incident response

Write an AI-specific incident response plan covering prompt injection, data exfiltration, and tool compromise scenarios
Define severity levels for AI security incidents
Run tabletop exercises with your team

Where to start

If you're prepping for SOC 2, prioritize logging and access control (items 1-11). If targeting EU markets, focus on log retention and adversarial testing documentation. If an enterprise prospect just sent a security questionnaire, start with authentication, RBAC, and runtime protection - those are what procurement checks first.

None of this requires a massive engineering effort. Most of it requires deciding to do it and documenting that you did.

Full article with detailed framework mappings for each item here

23 Times my autonomous AI engine re-discovered teh same niche

Fri, 19 Jun 2026 18:23:15 +0000

2,667 startup ideas — and my AI engine kept coming back to the same niche 23 times

Since EvoRadar went live, the engine has been doing three things on autopilot: scanning global signals, generating startup ideas, and killing the ones that aren’t strong enough.

Here’s what the data looks like now.

INPUTS (signal scanning)

• 1,034 signals collected from 308 distinct sources — government filings, R&D announcements, funding rounds, regulatory drafts
• Signal mix: 47% technology, 29% regulation, 19% funding
• Single highest-frequency signal source: EU AI Act (45 distinct events) — ahead of FDA, Nvidia, CATL, MIIT

OUTPUTS (after the engine evaluated and scored each idea)

• 2,667 startup ideas generated
• 608 survived the kill gate — survival rate 22.8%. The other three out of four were cut for thin defensibility, weak timing, or incumbent capture
• Of those 608 survivors, 213 (35.0%) were compliance- or regulation-driven

That alone is worth a pause. But the next part made me look twice.

THE ACTUAL POINT: CONVERGENCE

Write on Medium
Across three independent engine iterations — with the signal mix rotating between US-heavy, Asia-heavy, and Europe-heavy weeks — the engine independently surfaced EU AI Act-related opportunities 23 separate times.

Not the same idea restated 23 times. Twenty-three different angles on the same niche: compliance kits for SMEs, conformity-assessment marketplaces, post-deployment monitoring dashboards, dual EU-China navigators, mechanistic interpretability audits…

Out of 2,667 ideas, the single highest-scoring one:

🎉 “EU AI Act Compliance Platform” — 7.67/10

Compliance-driven ideas have held a 29–65% share across all three engine versions.

WHY THIS IS WORTH STOPPING FOR

EvoRadar is designed to chase novelty. Its imagination layer is biased toward unexpected cross-domain pairings, not safe well-trodden categories. When an engine like that keeps converging — across versions, across signal mixes, across months — onto the same opportunity space, the bias isn’t in the engine. The market is sending a signal.

The EU AI Act enforcement window is now open. CBAM is expanding. GDPR enforcement is tightening. Tens of thousands of SMEs and non-EU AI exporters need to ship compliant products — and the existing tooling is either Big-4-priced enterprise consulting or DIY PDF templates from law firms.

That’s the gap. The engine surfaced it 23 times.

WHAT’S NEXT

Given a signal that strong, I decided to build the tool myself — ComplianceLint, an EU AI Act compliance tool. Launching publicly in the next few days. A separate post will cover the architecture and positioning.

If you want to dig into the data behind this post, the engine’s idea database is live:

🔗 https://compliancelint.dev/
🔗 https://github.com/ki-sum/compliancelint

EUAIAct #AICompliance #BuildInPublic #SoloFounder

99.62% of “Bannered” Sites Still Trigger Tracker Signals Pre‑Consent (Runtime Data)

Thu, 30 Apr 2026 08:31:06 +0000

TL;DR: Audited 276 websites and found that 95.65% of them had Cookie Banner (proxy checks) installed and 99.62% of bannered sites have pre-consent third‑party tracker signals still flagged by runtime audit engine.

In other words: banner presence was common, pre‑consent drift was almost universal in this sample.

The takeaway isn’t “banners are useless” It’s: a banner is UI but compliance is behaviour.
If you don’t verify what actually runs and what actually hits the network on a cold visit, you’re trusting configuration screens over browser reality.

Scope: EU/EEA GDPR + ePrivacy (cookies and similar identifiers). Educational, not legal advice.

Most teams treat “banner installed” as the finish line. Engineers and reviewers care about something stricter:

On a cold visit (no prior consent stored), do non‑essential scripts stay inert?
Do non‑essential third‑party requests stay off the network until consent is captured?
A CMP dashboard toggle can say “blocked” while load order, tag manager triggers, or embeds still fire early.

WHAT WE MEASURED (RUNTIME SNAPSHOT)

Dataset and scans were run with SecureSpells - GDPR & ePrivacy–focused runtime browser audit.

Dataset (aggregated only):

Sites scanned: 276
Consent banner detected: 95.65%
Pre-consent third‑party tracker signals flagged: 99.62% (of bannered sites; simplified proxy check)
Critical risk issues flagged: 68.06% (sites with ≥1 critical issue in issue counts)
30‑day regression rate: 3.57% (monitored domains with ≥1 regression event)
Interpretation: banners are common. Observed behaviour still drifts unless you verify it in a browser on a cadence.

Important: “flagged” here means the scan observed behaviour consistent with third‑party tracking/embeds happening pre‑consent under the scan profile. It does not decide lawful basis, jurisdiction, or final legal classification for a specific tag.

Drift usually comes from small changes that bypass the banner’s assumptions:

Tag manager edits (new triggers, containers, templates)
Third‑party embeds added by marketing (video, chat, booking widgets)
CMS/plugin updates introducing new scripts/endpoints
Consent mode configuration drift (signals update, but load order still leaks)
If your process ends at “banner installed,” drift accumulates until a client notices—often via a complaint or a screenshot.

THE WORKFLOW THAT HOLDS UP (AGENCY VERSION)

Treat privacy behaviour like performance regressions: a workflow, not a checkbox.

Baseline on staging (before launch) Run a runtime scan on the entry page under a “no consent yet” profile. Save the output as
evidence.
Gate the usual sources of drift Route marketing tags through a single policy/owner. Keep a written rule like:
No non‑essential third‑party requests before consent (adapt to your legal interpretation).
Re‑scan on change + on cadence After any GTM change, plugin update, or marketing release: re‑scan. Then re‑scan production
weekly/monthly depending on risk.

WHAT TO TELL CLIENTS (LANGUAGE THAT AVOIDS OVERCLAIMS)

“We installed a banner” → “We control and verify tracking behaviour under defined consent states.”
“We’re GDPR compliant” → “Here is runtime evidence for pre‑consent behaviour on the pages we tested; broader compliance still requires legal and operational work.”
“We blocked everything” → “We validated non‑essential third‑party requests don’t occur before consent in the tested profile; we monitor for regressions.”

CONCLUSION

The average state of public websites is, frankly, worryingly sloppy. A cookie banner creates a convincing UI, but it often creates a false sense of compliance when the underlying behavior still leaks: tags fire early, embeds bypass assumptions, and GTM/container edits drift after launch. The big gap isn’t “lack of CMPs” — it’s lack of runtime proof that a cold visit actually stays quiet until consent.

For agencies, this is an opportunity: “compliant websites” can be a real differentiator if you can back it with evidence, not promises. Make runtime scans part of delivery (staging baseline → launch evidence), then sell monitoring as a retainer (re-scan on change + cadence). If you want to reproduce this workflow, SecureSpells is a GDPR & ePrivacy runtime compliance browser audit: https://securespells.com/

READ THE FULL METHODOLOGY + LIMITATIONS

Full post (with methodology, limitations, and the agency workflow):
https://securespells.com/blog/banner-installed-tracking-stopped-runtime-data/

Own Your Consent Layer: Vibe Code, AI, and Runtime Proof With SecureSpells

Wed, 29 Apr 2026 11:45:14 +0000

TL;DR

You can ship a small first-party consent module fast (AI helps). The
part that actually holds up under scrutiny is whether non-essential
requests and scripts stay dead until valid consent in a real
browser. Treat a runtime audit like CI for privacy: red → fix load
order / injectors → re-scan. Skipping a heavy CMP does not mean
skipping proof after every deploy.

Scope: EU/EEA GDPR and ePrivacy (cookies and similar tech on websites). Educational, not legal advice — get counsel for your setup.

Who this is for: you ship or review what loads before consent: index.html and bootstrap order, GTM / container changes, SPA navigations where tags re-run, consent PRs, or infra + security pushes that assume “marketing fixed it in Cookiebot.” The goal below is reproducible proof—cold visit, real browser, same question after every merge—not a greener admin panel.

Commercial CMPs are the right choice for lots of teams. The failure mode for builders is different: the CMP becomes a black box. Marketing edits tags, A/B tests swap snippets, preview ≠ production. Without a runtime check you find out from a complaint, not from your pipeline.

What you want instead is evidence-first consent: “done” means you can point to reproducible proof that non-essential tags did not initialise or send data before consent — not only that a banner rendered.

THE LOOP: CODE → SCAN STAGING → READ FINDINGS → REFACTOR → RE-SCAN

Same rhythm as TDD, except the “test” is a browser execution trace:

In security or platform review, someone will eventually ask “show me Network for a cold visit” — not “screenshot Cookiebot green.” The loop exists so that artifact is repeatable after every deploy:

Freeze the surface — same staging URL, clean profile, same consent variant you ship.
Run a runtime audit — isolated browser; see what fires before accept/reject.
Pick one hypothesis — e.g. “Meta endpoints should not appear before accept.”
Change one thing — usually load order and when GTM / marketing bootstraps run, not cosmetic banner CSS.
Re-scan — until the checks you care about pass; repeat when marketing ships again.

Technically: Default deny (do not load the tag hub until your gate runs) is often easier to reason about than “load GTM and hope it waits internally.”

Lightweight patterns (details and caveats on the blog): keep third-party scripts inert (type="text/plain" until flip), one owner module for consent branches, optional MutationObserver as defence in depth — but the audit is still the referee; observers miss plenty.

WHAT AI IS GOOD FOR (AND WHAT IT IS NOT)

LLMs are great for boilerplate structure, naming, and refactoring if you paste ground truth into the thread: failing network evidence, the exact injector, your consent state machine. If the model is arguing from vibes instead of a trace, you are one deploy away from theatre.

Teams: Consider pasting the anonymised SecureSpells “Technical Details” JSON into the PR when you touch loaders or CMP config—same idea as a failing test log attached to CI. That gives reviewers the same artifact ChatGPT sees and stops “looks fine locally” merges.

THE BORING PARTS YOU STILL OWN

A custom gate can be more inspectable than a hosted script — if you close gaps: consent logging (Art. 7 is not satisfied by localStorage alone), withdrawal UX, granularity that maps to real load branches, geo / TCF if you play in ads, vendor registry if you dropped the CMP crawler, transfers (Chapter V) even when execution looks clean.

Full honest checklist + comparison dimensions + LLM paste bundles:
Own your consent layer — test-driven privacy (full article)

LIMITED LAUNCH (SECURESPELLS)

We’re running a small launch window: first 30 Stripe checkout redemptions get Pro with full audits at €29 for the first month (then renews at list price — always confirm in Stripe, incl. VAT). That tier includes ongoing monitoring plus the runtime evidence story above — i.e. not “a cheaper banner,” but verification + regression signal after you ship.

Start here: https://securespells.com/

If the offer is exhausted or past the campaign end date, the page should reflect that — don’t rely on this article alone.

Compliance as an engineering problem: building an open-source IS, Privacy and AI Governance Platform

Fri, 24 Apr 2026 00:05:46 +0000

Compliance as an engineering problem: building an open-source Information Security, Privacy and AI Governance Platform

There are two kinds of compliance tooling on the market. The first is a spreadsheet dressed in good intentions. The second is a contract with a golf invitation attached. I spent a few years watching organisations pay handsomely for the second while quietly operating the first underneath it, and eventually decided to find out what it would take to build something that was neither.

This post is the architectural write-up. Not a pitch — I'm not selling anything. Just the decisions, the trade-offs, and the parts that were actually hard. If you've ever looked at the GRC market and wondered whether the prices were commensurate with the engineering, you're the intended reader.

The thesis

Treat compliance implementation as an engineering problem, not a consulting exercise. Every artefact — the policy, the implementation guide, the self-assessment scorecard, the crosswalk to other frameworks — should derive from the same structured source. Change a control, everything downstream updates consistently. Most commercial tools fail this test, which is why their "single source of truth" tends to drift within a quarter.

Every generated script and policy in the repo carries a QA_VERIFIED marker. If it hasn't been through the four-layer validation pipeline — existence, keyword coverage, semantic similarity against a 45-standard normative reference corpus (ISO 27001/27002/27701/27018/42001, NIST 800-series, GDPR, DORA, NIS2, PCI DSS, ENISA, NSA, CSA, OWASP, MITRE ATT&CK, and more — about 5,000 indexed chunks), and finally a Claude-driven gap analysis with reasoning — it doesn't ship.

The first principle is that you must not fool yourself, and you are the easiest person to fool. — Feynman

Pinned to the README for a reason.

The stack

Backend: Python / FastAPI
Frontend: React 19 / TypeScript / Vite / Tailwind / MUI 6
DB: PostgreSQL with Alembic migrations (currently at revision 053)
Search: OpenSearch for full-text across the document corpus
Queue: Celery / Redis for evidence connector jobs and daily KPI snapshots
Proxy: Nginx with TLS
Deploy: single docker-compose.yml, 10-service stack, runs on anything with Docker 24+

What it covers

Five content products, one Platform, four ISO standards:

Framework — the full ISO 27001:2022 engineering product: 53 control packs covering all 93 Annex A controls, 188 Python generators for this product alone, 504 implementation guides (user and technical), multi-sheet assessment workbooks with automated scoring
Operational — a lightweight ISO 27001 foundation ISMS for SMEs: 53 operational policies with single-sheet compliance checklists
Privacy — ISO 27701:2025 extension: 21 control groups split across controller, processor, and shared, with 23 privacy policies and full GDPR Article 30 / RoPA traceability
Cloud — ISO 27018:2025 extension: 12 Annex A control groups for PII in public cloud, with SCCs, IDTA, and adequacy monitoring built in
AI — ISO 42001:2023 extension: 12 control groups for AI management system governance, with ISO 42005:2025 impact-assessment methodology structured in, plus EU AI Act + NIST AI RMF + OECD AI Principles crosswalks

Across all five: 317 Python generators, 590 implementation documents, ~377K lines of code, 99 control groups. All policy content renders in EN / FR / DE / IT across seven jurisdictions (CH / FR / BE / LU / DE / AT / IT / GB), with country-specific regulatory tokens applied at request time — no policy clones.

On the Platform side, 25 compliance assessment modules — NIS2, DORA, CIS Controls v8, BSI IT-Grundschutz, TISAX, NIST CSF 2.0, NIST AI RMF 1.0, EU AI Act, EU Cyber Resilience Act, EU Cloud Sovereignty Framework, BaFin BAIT, CSSF Circulaire 20-750, ACN Guidelines, Swiss nDSG, Swiss ISG (SR 128), Swiss CSRM (NCSC), UK NIS 2018, UK Operational Resilience (FCA/PRA), NCSC CAF v4.0, ReCyF v2.5 (FR NIS2), ISO 27701, ISO 27018, ISO 42001, ISO 42005, and more — connected by 3,315 cross-framework mapping objects across 41 regulatory axes.

44 automated evidence connectors pull from the usual suspects and then some:

Microsoft: Entra ID, Defender, Sentinel, Intune, M365, Azure CSPM
Network: FortiGate, Cisco, Zscaler, PAN-OS
Identity: AD, LDAP, CyberArk, Vault
Vulnerability: Qualys, Tenable, CrowdStrike, SentinelOne, Wazuh
ITSM: ServiceNow, Jira
Monitoring: PRTG, Graylog, Zabbix
Cloud posture: AWS Security Hub, Azure CSPM, GCP SCC
Threat intel: OpenCTI, OpenAEV

Threat intelligence is wired in through a dedicated feeds container pulling seven sources on schedule:

MITRE ATT&CK v18 (835 techniques, 187 threat actor groups, 787 software entries, 52 campaigns)
MITRE ATLAS (AI/ML adversarial)
CISA KEV (daily)
FIRST EPSS (daily)
NVD CVE (~345K entries, CVSS 2/3/4.0)
NVD CPE
ENISA EUVD (full weekly + delta daily — exploited vulnerabilities and EU-assigned CVEs from ENISA, NCSC-FI, NCSC-NL, CERT-PL, and other EU CERTs, cross-enriched against NVD)

The ATT&CK heatmap supports Navigator-style filtering by actor, sub-technique, and software attribution. The EUVD Explorer surfaces EU-designated exploited and critical vulnerabilities relevant to NIS2 Article 23 reporting obligations.

The odds and ends that took longer than expected: EBIOS RM (full 5-workshop ANSSI methodology), BIA with RTO/RPO/MTPD, TPRM with DORA ICT fields, 5×5 risk register with BSI 200-3 scoring, Projects Workspace with document-variable substitution and in-platform WYSIWYG editing, a Cytoscape.js control dependency graph (229 intra-ISO-27001 relationships), six-role RBAC with multi-org support, TOTP MFA.

The parts that were actually hard

The hardest part, by a considerable margin, was the crosswalk methodology. Mapping over 3,400 relationships between twenty-three frameworks with defensible confidence scores is not a one-afternoon job, and the internet is full of crosswalks that collapse on inspection. Structured domain tagging plus human review on every mapping was the only approach that produced something I'd stake my name on.

Multilingual policy generation was the second-hardest. Legal and regulatory tone doesn't translate cleanly — each jurisdiction has its own conventions, its own preferred phrasings, its own idea of what "reasonable" means in a control objective. The architecture settled on runtime rendering with country-specific regulatory tokens rather than maintaining separate policy forks per jurisdiction. There is no shortcut, and machine translation alone will embarrass you in front of an auditor.

The QA engine was the third. A one-shot LLM "does this policy cover the control" is not serious engineering — the model will cheerfully hallucinate coverage it cannot substantiate. The four-layer pipeline exists because each layer catches a different class of failure:

Existence catches missing artefacts
Keyword coverage catches shallow drafts
Semantic similarity against the 45-standard reference corpus catches policies that sound right but say the wrong thing
Claude gap analysis with reasoning catches everything the other three miss

Removing any of them visibly degrades the output.

The stack choices — OpenSearch for the document corpus, Celery/Redis for the connector fleet and KPI snapshots — were deliberate and I'd make them again. Full-text search across ~590 implementation documents plus 5,000+ reference chunks is not a job for PostgreSQL's tsvector, and 44 evidence connectors running on their own schedules need a real queue. At this scope, those are table stakes, not luxuries.

If you want to look under the hood

Repository: github.com/isms-core-project/isms-core-platform — Docker Compose, self-hosted, no subscription fee
Site with the full tour: isms-core.com

Happy to discuss any of the architectural decisions, the crosswalk methodology, the QA pipeline, or the runtime multilingual rendering in the comments.

The Moment Your App Becomes a Liability: A Deployment Rule for AI in Healthcare

Tue, 21 Apr 2026 16:05:10 +0000

The Zurich Case: Operational Success vs. Compliance Architecture

A clinician in Zurich recently watched a short video explaining how easy it now is to build software with AI. The message landed the way it lands for thousands of practitioners every week: this is the tool that finally closes the gap between what I need and what IT can build for me.

So they built it. A weekend. A coding agent. A custom patient management application, loaded with their entire patient database, connected to two US-based AI services for automatic transcription of appointment audio. No vendor. No waiting. No manual notes.

They were not being reckless. They were solving a real problem, using the best available tools, in exactly the way those tools were designed to be used.

Three weeks later, a security researcher spent thirty minutes in the waiting room and walked out having read and rewritten every patient record in the system. One terminal command. The entire "security" layer was client-side JavaScript in a single HTML file.

When notified, the clinician responded with a message that the researcher described as 100% AI-generated. Warm, professional, entirely missing the point.

I want to linger on that clinician for a moment, because this story is not about negligence. The clinician had domain expertise, patient relationships, and a genuine operational problem to solve. What they lacked was a single question that nobody in the build process had asked: what will this system do with patient data, and can another party trace and verify that answer?

That question is not a technical formality. It is the dividing line between a system that is operational and a system that is deployable. In healthcare, only one of those is legal.

The Pattern Has Already Been Enforced, at Scale

Before calling the Zurich case a vibe coding problem, it is worth establishing that the same structural failure has already been enforced, repeatedly, against organizations far better resourced than a solo practitioner.

Between 2023 and 2025, US healthcare organizations paid over $100 million in fines and settlements for one class of failure: patient data moving through third-party services that nobody had mapped against regulatory constraints before deployment.

Cerebral embedded Meta Pixel, TikTok, Google, and Snapchat trackers inside the onboarding forms where patients described their anxiety, depression, and medication histories. This ran for four years and affected 3 million users. The FTC fined the company $7 million and permanently banned it from using patient health data for advertising, severing the company's primary growth mechanism. The former CEO was named in the complaint personally.

Advocate Aurora Health deployed Meta Pixel on authenticated patient portal pages. The marketing team integrated it exactly as Meta's documentation instructed. Nobody had modeled what protected health information that pixel would capture once a patient was logged in. The result was a $12.25 million class action settlement affecting 3 million individuals.

The notable thing about Advocate Aurora is not that they failed. It is how they failed. They had a compliance function. The failure was not the absence of oversight. It was a structural separation: the team that deployed the component and the team responsible for patient data privacy were operating on different tracks, and no process required them to intersect before deployment. That separation is exactly what no-code and vibe-coded workflows institutionalize as the default condition.

BetterHelp. GoodRx. Over $100 million in total. The average cost of a US healthcare data breach in 2025 reached $10.22 million, the highest of any industry, for the fourteenth consecutive year.

In each case, the component was integrated correctly by its own technical documentation. The failure was not a configuration error. It was a prior absence: nobody had characterized what that component would do inside a real clinical data environment before it was deployed.

Why This Keeps Happening to Organizations That Should Know Better

Here is the question the enforcement record raises but does not answer: why does this pattern appear across organizations with legal teams, compliance officers, and awareness of regulatory risk?

The answer is not that these organizations were careless. It is that the failure is structurally produced by how software gets built.

AI coding tools are optimized to generate code that runs. Running is the success criterion. The workflow declares victory at the moment the application works. Whether that working application can be independently reviewed, whether its data flows are legally characterized, whether an auditor could reconstruct what it did and under what authority twelve months later: none of those are part of what the tool is measuring.

The tool succeeds at the exact moment the compliance problem begins. Silently. And because the system works, there is no internal signal that anything is wrong. A system built without data flow characterization cannot surface the fact that its flows are uncharacterized. The absence is structurally invisible until external pressure is applied — a researcher in the waiting room, a regulator with a subpoena, a class action filing.

This is the mechanism that connects the Swiss clinic to Cerebral to Advocate Aurora. They are not different stories about different failures. They are the same story: a component was placed into a regulated data environment without a prior layer of characterization. The mechanism that placed it was different. The missing precondition was identical.

What vibe coding changes is not the failure mode. It is the velocity. The Cerebral tracking architecture took years to build and years for regulators to identify. A no-code healthcare application can reproduce the same structural exposure in an afternoon. The regulatory frameworks do not adjust for speed. HIPAA does not include an exception for AI-generated code. The EU AI Act's clinical-adjacent software provisions become enforceable in August 2026 regardless of how the application was assembled. The structural exposure is the same, even if the regulatory path differs.

As these tools become more capable, the distance between "working application" and "deployment decision" continues to compress. What does not compress is the regulatory exposure. The gap between the moment the tool declares success and the moment a legal obligation attaches does not shrink as the tooling improves. It only becomes easier to cross without noticing.

The Standard That Changes This

The missing layer has a name, and it is worth defining precisely.

Compliance architecture is not a checklist applied after the code is written. It is a prior layer of characterization that must exist before any component is introduced into a patient data context. It answers four questions:

What data will this component touch?
Where will that data move?
Under what legal authority does it move?
How would an auditor reconstruct that path twelve months from now?

That is the design requirement that makes a system deployable rather than merely operational. No-code tools do not ask it. AI coding agents do not ask it. The organizations that avoid enforcement are not the ones using different tools. They are the ones who ask it anyway, before deployment, not after a breach notification arrives.

This is also why the fix is not slower tooling or avoided automation. The fix is a prior question asked at the right moment in the build process.

The deployment standard is simple: can another party trace what this system did, under what authority, and to whom?

If that question does not have a documented answer before the first patient record enters the system, the application is operational-looking. It is not deployable.

Where This Leads

OCR's 2026 enforcement expansion specifically targets organizations that have not conducted risk analyses. A practitioner who built a patient management application with an AI coding agent and skipped risk analysis is very close to the kind of failure this initiative is designed to reach.

The enforcement cases so far have concentrated on covered entities with institutional structure: compliance teams, legal counsel, vendor relationships. The structural risk is increasingly concentrated below that threshold, among solo practitioners, small clinics, and health tech founders who have none of that infrastructure and no organizational layer between the coding agent's output and a production deployment.

Those cases have not arrived yet. They will. And when they do, they will be public, permanent, and attached to names on a breach portal that the industry calls the Wall of Shame.

Platform-level guardrails are improving but are structurally misaligned: the growth incentive of no-code platforms runs in the opposite direction from what regulated deployment requires. Enforcement will build the market for domain-aware compliance tooling before voluntary platform governance will. That tooling is technically feasible. It does not yet exist at the scale or accessibility the problem requires.

Until it does, the verification is manual.

Verify before you deploy. Or someone else will do it for you, after a breach, under subpoena.

Flamehaven builds governance architecture for AI systems in high-stakes environments. The full technical analysis behind this piece, including enforcement data, regulatory framework, and deployability evaluation methodology, is at: The $100 Million Blind Spot: What No-Code Healthcare Builders Still Don't See

For direct conversation about where your system's deployability gap actually is: flamehaven.space/contact

DAIS-10: A Story, A Reality and infinite utility

Tue, 31 Mar 2026 11:30:53 +0000

"The Story" "Why DAIS‑10 Exists

Every organization begins with clean, fresh customer records, accurate details, and the belief that this information will guide smart decisions. But over time, something quiet and destructive happens behind the scenes. The data starts to age. Some customers haven’t been active in months. Phone numbers change. Addresses become outdated. Fields go missing. Entire rows lose their meaning. And slowly, without anyone noticing, the company’s most valuable asset begins to rot. Teams try to keep up. Analysts run reports. Governance teams review spreadsheets. Compliance officers worry about retention laws. Marketing complains about bad CRM results. Executives wonder why decisions feel “off.”

But the truth is simple: Data decays faster than humans can manage it. That’s the world DAIS‑10 was born into.

Need of DAIS10:

Why DAIS‑10 Exists Modern organizations drown in data problems that quietly destroy revenue, accuracy, and compliance. DAIS‑10 solves the seven most expensive ones:

Stale Data: Customer records lose value every month. DAIS‑10 scores decay automatically so teams know what to keep, refresh, or retire.
Missing Values: Incomplete entries drag down decision quality. DAIS‑10 detects missing critical fields and adjusts row level importance instantly.
Retention Policies: Every industry has strict data retention rules. DAIS‑10 calculates how long each record should be kept and when it must be removed.
Data Quality: Bad data costs companies millions. DAIS‑10 assigns quality scores to every row, highlighting weak, risky, or unreliable entries.
Data Governance teams: spend endless hours manually reviewing datasets. DAIS‑10 automates scoring, classification, and prioritization.
Time Decay: CRMs rot over time — outdated phone numbers, old addresses, inactive customers. DAIS‑10 identifies which records still matter.
Compliance with Retention Laws: GDPR, CPRA, PIPEDA, and industry specific rules require strict data handling. DAIS‑10 provides deterministic, audit ready scoring. give me this in story form!

Test your Sample Data, Follow and give feedback if like!

https://zulfr.com/app/

Emails are not allowed

DAIS-10 = DATA ATTRIBUTE & IMPORTANCE STANDARD!

DAIS10: The Tool That Shows You What Your Data Is Really Worth,

DAIS‑10:“Define the Schema & Data Makes Sense Beyond Imagination.” For ML and AI engineers, data and data movement give meaning to goals, outcomes, and utility. DAIS‑10 applies a Dual‑Importance Strategy!

You started with structure.
You learned how to categorize, normalize, and enforce consistency.
This was your “database theory” phase.

Today I’m releasing something I’ve been building quietly. DAIS10, a simple but powerful way to understand the real value of your customer data.

Here’s the reality:

Most organizations don’t know which data is strong, which data is fading, and which data is holding them back. They’re making decisions in the dark.
DAIS10 turns the lights on.

It shows you:
⭐ Which customer records are strong
⚠️ Which ones are incomplete or weak
⏳ Which ones are losing value over time
Which fields matter most for your business
How a single missing entry can drop the importance of a whole record

No complexity. No jargon.
Just a clear score that tells you, “This data is useful” or “This data needs attention.”
I’ve shared a visual example so you can see DAIS10 in action. And the best part?

You can try DAIS10 for free.

This was the first thing I created. It is a tiny step in a bigger vision I’m building around data clarity, intelligent scoring, and practical AI‑ready systems.

Much more are already developed, just waiting to post them in a pattern!

An Example to Understand DAIS-10!

Let’s understand DAIS10 with a simple real‑world example. Before a surgery, a patient fills out a medical intake form. In one case, the patient forgets to mention allergies. In another case, a different patient forgets to tick the box for hospital subscription and marketing services. Both are technically “missing values,” but they are not equal in importance. Forgetting allergies can directly affect patient safety. Forgetting marketing preferences has no impact on medical decisions. DAIS10 is built for exactly this kind of situation. It doesn’t treat all missing values as equal — because in real life, they aren’t. DAIS10 assigns higher importance to fields that matter more, and lower importance to fields that don’t. This is why DAIS10 makes sense for anyone who understands that not all data carries the same weight or utility.

DHS Trusted Tester Certification Study Group: Mastering Dynamic Web Content

Tue, 10 Mar 2026 07:35:30 +0000

Last week, we looked at and listened to the symphony of dynamic webpage content. If Session 1 was the quiet theory of Section 508, Session 2 was the loud, blinking, scrolling reality of the web. We tackled the trio of auto-playing audio, moving/blinking content, and auto-updating information, along with a critical detour into flashing content and seizure safety.

Resources

As always, the slides, transcripts, and a condensed summary are available on the respective GDG Vienna event pages as well.

Study Group Session 2

The overarching theme of the session was the Numver 3: Whether it’s a button to pause an audio track, a link to stop a scrolling ticker, or a dialog to hide a live update, the Trusted Tester process demands that the mechanism to control these elements be found within the first three interactive elements a user encounters (or within three elements before or after the moving content).

It’s a strict, pragmatic rule designed to ensure that users aren’t forced to hunt for a “stop” button while being bombarded by sensory input.

Audio Control: The Three-Second Threshold

We started with the basics of audio. If audio plays automatically for more than three seconds, a mechanism must exist to pause, stop, or control the volume independently of the system volume. We walked through several examples: a passing case where a “Stop Ad” button sat right at the top of the page, and a failing case where a “Silent” link was buried fifteen elements deep, forcing keyboard users to tab through a maze just to find relief. The lesson? If the mechanism exists but is hard to find, it fails. Accessibility isn’t just about having a feature; it’s about making it reachable.

Blinking, Moving, and Scrolling

Next, we looked at visual motion. Any content that moves, blinks, or scrolls for more than five seconds in parallel with other content requires a pause, stop, or hide mechanism. We debunked a few myths: a loading spinner that prevents interaction is often considered “essential” and thus exempt, but a scrolling news ticker is not. We also saw a clever example where a blinking “Submit” button could be stopped via a keyboard shortcut (Ctrl+S), proving that text instructions can count as a valid mechanism—if they actually work. Unfortunately, we also saw a failing example where the shortcut was documented but broken, reminding us that documentation doesn’t equal functionality.

Auto-Updating Content: Live Regions and Dialogs

The session then shifted to content that changes on its own, like stock tickers or sports scores. Here, the rules are similar: users need a way to pause or hide the updates. But we also introduced the concept of Change Notification. If content updates automatically, how does a screen reader user know? We explored three valid methods: a keyboard-accessible dialog, moving focus to the new content, or using an aria-live region. Using the ANDI tool, we visualized how live regions highlight in purple, making it easier to spot if dynamic content is properly announced. We saw a passing example where a hockey score update was contained in a live region, and a failing one where a dialog box appeared but couldn’t be triggered by keyboard, rendering it useless for many.

Flashing Content: The Seizure Safety Net

Finally, we touched on the most critical safety issue: flashing content. While the Trusted Tester process marks flashing content as “not tested” (since it requires specialized tools like the Photosensitive Epilepsy Analysis Tool - PEAT), we strongly emphasized that this doesn’t mean it’s safe to ignore. Content that flashes more than three times per second can trigger seizures. We reviewed examples where a “stop animation” button existed but was too far down the page, and where blinking text was indistinguishable from flashing. The takeaway: even if the formal test says “not tested,” the ethical and safety obligation to prevent seizures remains.

Knockout Criteria

A recurring point in the session was the “knockout” nature of these tests. If a mechanism fails any applicable test condition (like color contrast on a “Pause” button, or keyboard accessibility on a dialog), the entire feature fails. It’s a rigorous standard that leaves no room for partial credit.

Homework

Your task this week is to complete the knowledge checks for auto-playing, auto-updating, and flashing content. If you haven’t installed ANDI or the TPGI Color Contrast Checker yet, now is the time! You will need them.

Next Session

Get ready for a deep dive into Keyboard Access and Focus. This is a massive topic, so we’ve moved the next session to Thursday, March 12th at 18:00 GMT+1 (note the day and time change!). We’ll be covering focus order, visible indicators, and keyboard traps. It’s going to be a long one, so bring your coffee.

DHS Trusted Tester Study Group Session 1 Recap

Sun, 15 Feb 2026 11:45:42 +0000

Together with the Google Developer Group Vienna, I am hosting a study group for the Trusted Tester certification. You can watch the previous session recordings on YouTube and access the presentation and transcript.

The next session will be on Friday March 6, 4 PM CET, on GDG Vienna.

What is Section 508?

Section 508 is part of the Rehabilitation Act of 1973. that requires any ICT developed, procured, maintained, or used by the U.S. Federal government to be accessible to people with disabilities. It guarantees that federal employees and the public can use government‑provided software, websites, hardware, and documents.

The DHS Trusted Tester program is a manual‑testing methodology created by the Department of Homeland Security.

It follows the ICT Testing Baseline and produces repeatable, reliable conformance results, and gives you a concrete, audit‑ready way to prove that a product meets Section 508 – far more trustworthy than relying only on automated tools.

The study group is free and 100% online. We meet every other Friday for ~6 months to go over the testing topics and examples from the Trusted Tester course. To recieve a certification, you must enroll in and complete the DHS Trusted Tester course.

Session 1 covered:

Functional Performance Criteria

Vision: No‑vision (screen reader), limited vision (magnification), no
colour perception (color contrast)
Hearing: No‑hearing (captions, transcripts), limited hearing (visual
alerts)
Speech: No‑speech
Manipulation Limited: fine motor control (keyboard‑only navigation)
Reach & Strength: Ability to press large targets, use assistive
switches
Language / Cognitive: Simple language, clear instructions, consistent
navigation

These map directly to the POUR principles (Perceivable, Operable, Understandable, Robust) that you’ll see throughout the course.

Electronic content beyond the web

One of the most eye‑opening moments for many participants was the realization that “electronic content” is a catch‑all term that includes PDFs, e‑books, emergency alerts, automated emails, survey forms, and even kiosk interfaces. The same accessibility principles that govern HTML also apply to these formats, albeit with different testing techniques.

For PDFs, for instance, you still need proper tagging, logical reading order, and descriptive alt text for images.

For e‑books, the focus shifts to structural markup that allows a screen reader to navigate chapters, tables of contents, and footnotes. The overarching message was clear: once you master the core concepts, you can transfer them to virtually any digital artifact.

Your Homework, should you choose to accept it

If you plan on taking the certification at the end of the study group, here is your homework until the next session: Complete the first 3 modules we covered in the DHS CX Directive.

What is Section 508? – theory & history
Standards for Web – POUR, WCAG, Functional Performance Criteria
Testing Tools – ANDI, autoplay settings, and contrast checker

Explore the ANDI bookmarklet on a few of your own sites, and familiarize yourself with the contrast‑checker.
Also: Check how to enable your browser’s autoplay ahead of the next session because the topic will be “auto‑playing & Auto‑updating content”.

Should you encounter any broken links in the official course, let me know. I’ve saved copies of the older resources.

Materials

Legal Data Vs. Illegal Data!

Sat, 07 Feb 2026 14:17:51 +0000

One line

Regulations force ETL when raw data cannot legally land in the warehouse.

Two words

Compliance pressure.

Business analogy

If the law says you must wash vegetables before they enter the kitchen, you can’t store them dirty in the fridge—even if the fridge is powerful enough to clean them later.

Why teams fall back to ETL under regulation?

1) Raw data is legally “toxic”: Some data cannot be stored in raw form, even temporarily.

Examples:

Personal health information
Financial identifiers
Government‑classified fields
Location data tied to individuals

If the raw payload violates:

GDPR
HIPAA
PCI‑DSS
FedRAMP
SOC2

…then ELT becomes illegal.

ETL solves this by stripping or masking sensitive fields before landing.

2) Data residency laws

Some countries require:

data to be transformed anonymized aggregated before it crosses
borders.

ELT would land raw data in a global warehouse first, which breaks the rule.

ETL lets you:

transform locally
remove identifiers

then ship the safe version

3) “Right to be forgotten” conflicts

If raw data lands in a lakehouse, you must delete it everywhere.

In ELT:

raw zone bronze silver gold backups replicas

This becomes a compliance nightmare.

ETL avoids this by never storing the sensitive raw version.

4) Vendor risk and auditability

Some industries require:

deterministic transformations auditable pipelines fixed logic
controlled environments

ELT encourages:

ad‑hoc SQL multiple consumers touching raw data uncontrolled
transformations

ETL centralizes logic in a controlled pipeline.

5) Data minimization principle
GDPR Article 5 says:

“Only collect what is necessary.”

ELT stores everything first, then filters later.
ETL filters before storage, satisfying the principle.

How teams decide (the real decision tree)

Step 1 — Can raw data legally land in storage?

Yes → ELT

No → ETL

Step 2 — Does the data contain regulated identifiers?

Yes → ETL

No → ELT

Step 3 — Do we need cross‑border movement?

Yes → ETL

No → ELT

Step 4 — Do auditors require fixed, controlled transformations?

Yes → ETL

No → ELT

Step 5 — Do we need raw data for ML or RCA?

Yes → ELT

No → ETL

The hybrid truth (what modern teams actually do)
Most mature organizations end up with:

ETL for regulated data

ELT for everything else

This is the “compliance‑first” architecture.

Summary:

Why ETL still exists (and why regulation is the real reason)

Everyone loves to say “ELT won.” Modern warehouses are powerful. Compute is cheap. Storage is infinite. But regulation doesn’t care how powerful your warehouse is. When raw data cannot legally land in storage, ELT stops being an architecture choice and starts being a compliance violation.

Why teams fall back to ETL in regulated environments:

• Some raw data is legally “toxic” (PHI, PCI, classified fields, precise location data)
• Data residency laws require transformation before crossing borders
• “Right to be forgotten” becomes unmanageable once raw data fans out
• Auditors demand deterministic, controlled, and auditable transformations
• GDPR’s data minimization principle conflicts with “store everything first”

So the real decision tree is brutally simple:

Can raw data legally land in storage?

→ Yes: ELT
→ No: ETL

The mature outcome isn’t ideological. It’s practical.

ETL for regulated data.
ELT for everything else.

That’s not legacy thinking.
That’s compliance-first data architecture.

If you’re designing modern platforms and ignoring this distinction, you’re not being modern—you’re being lucky.

Infect, Governance and compliance had pushed me to dive deeper into the semantics of data. One of my original efforts in that direction is DAIS‑10.

https://github.com/usman19zafar/DAIS-10-Continuum

SHIPPED25: The Research Panel

Tue, 09 Dec 2025 21:43:05 +0000

In this panel discussion, Matt Allford, Charlotte Fleming, and Steve Fenton walk through some of the key findings from the research projects that took place at Octopus Deploy this year.

The State of GitOps report

The State of GitOps report investigates the adoption, practices, and benefits of a GitOps approach. Our research is based on data from 660 survey responses and interviews with a panel of experts and practitioners.

The Platform Engineering Pulse report

The Platform Engineering Pulse report reveals how organizations implement Platform Engineering today, what's working, what isn't, and why. We surveyed technical professionals across industries and roles to understand the gap between Platform Engineering theory and reality. The research explores what drives adoption decisions, which platform features deliver real value, how teams measure success, and which strategies actually move the needle.

Compliance through Continuous Delivery

This report, surveying 50 financial organizations in 2025, shows how automated Continuous Delivery pipelines can simultaneously increase throughput and stability, resolving the speed-versus-safety trade-off.

Coder Legion - Recent posts tagged compliance

Free AI Policy Template (UK): Every Rule Has a Control

Free AI Policy Template (UK): Every Rule Has a Control

What should an AI policy include?

The free AI policy template (copy and adapt)

Section 1. Purpose and scope

Section 2. Approved tools

Section 3. Data you must never put into an AI tool

Section 4. Human review of AI output

Section 5. Decisions about people

Section 6. Transparency

Section 7. Ownership and accountability

Section 8. Incidents and stopping a tool

Section 9. Training

Section 10. Review

Do UK businesses legally need an AI policy?

Should you ban ChatGPT and other AI tools at work?

How do you enforce an AI policy once it is written?

Does the EU AI Act change what goes in a UK AI policy?

How much does an AI policy cost to put in place?

Who is this template not right for?

What should you do this week?

Related reading

SOC 2, CRA, NIS2: they all ask your cluster the same five questions

tags: security, kubernetes, devops, compliance

Where SOC 2 came from, and why that still shapes it

Type I and Type II

The five criteria, and the four you probably do not need

SOC 2 does not tell you what to do

The other instruments, and their clocks

They are all asking the same five questions

What good evidence looks like

Why the admission controller is the right place to stand

How we built this into Attestkeep

What this does not do

If you take one thing

GPT-6 Astra: What to Decide Before You Switch It On

Who this guide is for

Three facts, not the benchmark table

1. It is off until an admin enables it

2. It is the first model rated Critical for cyber capability

3. It is harder to monitor, by OpenAI's own testing

What you gain, and what you can no longer see

From inside the company that built it

Critical is a word with a published definition

Who should enable it, and who should wait

Five things to settle before you enable it

What we are doing with it, and where we are not

Questions we are actually getting

The bottom line

Two Complaints in Two Years: New York City's AI Hiring Law Made a Record Nobody Can Read

What the law asked for

The first count, 2023

Null compliance is not non-compliance

The second count, 2025, by the state

What would make the zero legible

A disclosure record is only as readable as its population

The crucial policy pattern

The allow/deny pattern

Crucial but not sufficient

AI Chatbot Security and Governance: What Every Business Needs Before Launch

Security Controls and Access Permissions

Data Boundaries: What the Bot Should Never Touch

Guardrails, Input Filters, and Output Policies

Topic Boundaries and Refusal Thresholds

Escalation Thresholds and Human Handoffs

Audit Controls and Ongoing Monitoring

Compliance Basics: Privacy and ISO 27001

A Pre Launch Governance Checklist

Why This Stage Protects the Whole Investment

Frequently Asked Questions

Building on a Secure Foundation

80% of Companies Are Already Out of Step With the AI Act and Don't Know It

The AI Act assumes an engineering floor you may not have built

Scope this before you panic

The reason capability outran the floor

What this actually requires of you

The Compliance Ratchet

How the EU AI Act's Risk Tiers Actually Classify Your AI System

Change Approvals