What a badge says, and what a regulator asks
| Question | What a vendor badge answers | What a regulator asks |
|---|---|---|
| Coverage | A framework name | Which products, on which tier |
| Contract | Nothing | Will you sign a business associate agreement |
| Decision | Nothing | Reconstruct this specific answer |
| Explanation | Nothing | What role did the system play |
Our governance and security hub covers the architecture behind these answers, and governance tools for AI agents scores the vendors on enforcement point.
What actually changed, and when
Three developments reset the compliance picture for AI analytics, and two of them removed obligations rather than adding them.
| Instrument | What happened | Effective |
|---|---|---|
| EU AI Act, general application | Applies | 2 August 2026 |
| EU AI Act, high-risk Annex III | Deadline moved later | 2 December 2027 |
| EU AI Act, high-risk Annex I | Deadline moved later | 2 August 2028 |
| DORA | Applies to EU financial entities | 17 January 2025 |
| CFPB circulars on adverse action | Withdrawn | 12 May 2025 |
| SEC predictive data analytics rule | Proposal withdrawn | 17 June 2025 |
| HIPAA Security Rule update | Proposed, still pending | Proposed 6 January 2025 |
The two withdrawals deserve care. The CFPB withdrew its circulars on adverse-action notices and complex algorithms. Those circulars held that model opacity is no excuse for failing to give specific reasons. The statutory duty under the Equal Credit Opportunity Act to give specific reasons survives. The interpretive guidance telling you that a black box will not satisfy it does not.
Fix the Context, Not the Model. A well-governed semantic layer that understands business context creates more reliable AI-driven analytics than fine-tuning the model itself. Regulation pushes the same way. An explainability requirement is easier to meet when the system compiles a traceable plan than when it generates prose about a black box.
How to read a vendor compliance page
There is a clear split in how carefully vendors describe their position, and it is visible in an afternoon.
The cloud platforms are precise. AWS publishes a named list of HIPAA-eligible services, requires a business associate agreement, and names exclusions inside otherwise eligible services. Google states that no HHS-recognised HIPAA certification exists and then lists which products its agreement covers. Snowflake routes protected health information through a specific edition plus a signed agreement. Its documentation compliance index does not list HIPAA as a certification at all.
Several BI vendors are not. Some present HIPAA in a row of badges beside SOC 2 and ISO 27001, with no scope statement, no date, and no wording. The same pattern shows up in accuracy claims, as AI data analyst tools sets out. SOC 2 and ISO 27001 are attestations against a defined scope. HIPAA is a law with no certification scheme. Placing them in the same visual row implies a parity that does not exist.
The useful question is contractual rather than visual. Ask which legal entity signs and which products the agreement names. Ask which tier it requires, and what the vendor documentation says when nobody is selling to you.
Five questions for a regulated procurement
- Which legal entity signs, and for which products? A badge is not a contract, and coverage rarely spans the whole product line.
- Which tier does compliance require? Several vendors gate row-level control and audit features behind their top tier, so the compliant configuration is not the quoted one.
- Can you reproduce an answer from six months ago? Ask for a demonstration rather than an assurance.
- Where does the entitlement check run? Before the plan or after it, and what the log records in each case.
- What happens when the vendor swaps the model? If answers change when the vendor swaps models, your historical decisions are no longer explainable.
The fifth question catches people out, and it is the one deterministic vs probabilistic text-to-SQL answers. A system whose output depends on which model version answered cannot reconstruct a decision made under the previous one. That reconstruction is precisely what an examiner asks for.
The four gates a regulated query must pass
Regulation rarely names a technology. It names an outcome, and the outcomes reduce to four checks that must happen before results reach a person.
- Identity. The system resolves who is asking and under which role, before it plans anything.
- Row and column policy. Entitlements narrow the data in the plan, not the result set after the fact.
- Proven join path. The system verifies the relationship between tables rather than inferring it, because an invented join produces a confident wrong number.
- Reproducible record. The same question returns the same SQL, and the log ties an output to the exact statement that produced it.
The fourth is where most deployments fail an audit. A system that answers correctly but cannot reproduce the answer six months later gives a regulator nothing to examine. See auditable SQL for BFSI conversational analytics and HIPAA-compliant AI analytics.
The two sectors ask different questions
Financial services asks you to explain a decision. The Equal Credit Opportunity Act still requires specific reasons for adverse action, whatever the model architecture. DORA has applied to EU financial entities since January 2025 and reaches the third-party technology they depend on. FINRA published guidance in 2024 for member firms. Supervisory policies must cover model risk management, data integrity, and the reliability of the AI model itself. None of that asks whether your analytics are fast.
Healthcare asks you to justify access. The question is not why the model concluded something but why this person saw this row. Minimum-necessary access answers that question. Row and column policy applied before the query runs settles it; a filter on the result does not. A proposed update to the HIPAA Security Rule has been pending since January 2025, so the baseline may tighten.
Both sectors converge on the same architectural requirement from opposite directions. One needs the decision reconstructed, the other needs the access justified, and both need a record that survives the person who created it. Fine-grained access control covers the policy design.
What this looks like in practice
The pattern holds across sectors. In a confidential asset reconstruction company, the requirement was not faster answers but defensible ones. Every figure in a recovery evaluation had to trace to the statement that produced it. The regulatory framework had no tolerance for an unexplained number. The result was a reduction of more than 95 percent in evaluation cycle time with complete regulatory coverage, described in the BFSI case study.
In healthcare the constraint shifts from explanation to minimum necessary access, where the same compile-time check does the work. Conversational analytics for clinical data covers that architecture.
Where Colrows changes the math (our product)
Colrows compiles a question into deterministic SQL and applies the four gates above while the query takes shape. Identity and role resolve first, and row and column predicates narrow the plan. The compiler then proves the join path against a typed graph and records the compiled statement.
That ordering matters for an examiner rather than for a benchmark. A regulator asks what ran, who could run it, and whether the same question returns the same answer today. A system that generates a fresh query each time cannot answer the third question, however good the first answer was.
None of this makes a deployment compliant on its own. Compliance is a programme, not a product. The architecture only decides whether the evidence exists when someone asks for it.
A note on the claims
Regulatory dates come from the Official Journal of the European Union and the US Federal Register. Vendor compliance positions come from each vendor's own published compliance pages as of late August 2026. This page describes what published rules require and does not constitute legal advice, so confirm your own obligations with counsel. Colrows sells a competing product, and we wrote the sections above with that disclosed. We review this page quarterly.
Frequently asked questions
Is any AI analytics tool HIPAA certified?
No, because no such certification exists. Google states on its own compliance page that there is no certification recognised by the US Department of Health and Human Services for HIPAA compliance. The meaningful question is whether the vendor will sign a business associate agreement, which products that agreement covers, and on which pricing tier. A HIPAA logo in a badge row answers none of those.
When do the EU AI Act high-risk rules apply?
Later than originally legislated. Regulation (EU) 2026/1744 amended the timetable. It appeared in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. Standalone high-risk systems under Annex III now apply from 2 December 2027. High-risk systems embedded in regulated products under Annex I apply from 2 August 2028. General application of the Act began on 2 August 2026.
Does the EU AI Act cover credit scoring and insurance analytics?
Partly, and the carve-outs matter commercially. Annex III point 5(b) covers systems evaluating creditworthiness or establishing a credit score, but explicitly excludes systems used to detect financial fraud. Point 5(c) covers risk assessment and pricing for life and health insurance only, so property and casualty lines fall outside it. Profiling of natural persons removes the narrow-task exemption in any case.
What audit trail does a regulated deployment need?
Enough to reconstruct a specific decision after the fact. The AI Act requires automatic event logging across the system lifetime, and deployers of high-risk systems must retain those logs for at least six months. Article 86 gives affected people a right to a clear explanation of the role the system played in a decision. In practice the logs must therefore stay retrievable and tied to individual outputs.
