Compliance
AI in medicine: what ScaleQuality proves for you
Brazilian Federal Council of Medicine Resolution 2.454/2026 requires every medical institution, and every physician, that develops or contracts AI systems to maintain governance, classify risk and hand over audit reports when the Regional Council asks. This page shows, measure by measure, which evidence the platform produces and what remains the institution's own duty.
Capabilities and evidence for this reference
Who the resolution reaches
Article 14 says "the medical institution or the physician who develops or contracts". It does not reach only those who build AI: the hospital, the health plan and the clinic that merely use a third party tool also need a governance process. Enforcement sits with the Regional Council of Medicine (Art. 15), and the Technical Director answers for it (Annex III, III).
That opens a second front for health software vendors: the hospital that contracts them now needs the vendor's evidence in order to answer its own Council.
Annex III: the eight mandatory measures
Article 14 makes the Annex III measures mandatory. Each one below, with the matching evidence.
| # | What the resolution requires | What the platform produces |
|---|---|---|
| I | Transparency of AI use and governance, with regular reports in managerial language | Export with declared register, available telemetry and cost provenance per field. It does not replace assessment of clinical performance or bias. |
| II | Prevention and mitigation of discriminatory bias, with stratified analysis of outputs | Remains with the institution |
| III | Internal governance, with the Technical Director responsible for oversight | AI initiatives with a declared owner and an audit trail of who did what |
| IV | Interoperability, with open standards and APIs | The evidence API and SBOM do not prove clinical interoperability. The institution must assess interfaces of the AI system used in care. |
| V | Auditable, configurable solutions rather than black boxes | The published methodology explains ScaleQuality measurement; adaptability and configuration of the clinical solution require a separate assessment. |
| VI | Lifecycle managed as a product: requirements, validation, testing, deployment, periodic review in production, defect correction and safe evolution | Engineering and code maturity measured and versioned, quality gate in CI, fixes proven by re-scan, continuous vulnerability inventory |
| VII | Integration interfaces with other institutions' health information systems | The evidence API and SBOM do not prove clinical interoperability. The institution must assess interfaces of the AI system used in care. |
| VIII | Access for oversight bodies to audit, monitoring and configuration reports | Audit export carrying the source of each block, action trail in CSV or JSON, compliance diagnostic as PDF |
In the body of the resolution
| Article | Requirement | Evidence |
|---|---|---|
| Art. 9 §2 | Specialised audit and continuous monitoring mechanisms | Measurement on every build, with versioned history comparable across dates |
| Art. 17 | Security measures matching the state of the art and the criticality of the data | Code security analysis, secrets, infrastructure configuration and CVEs in dependencies and container image |
| Art. 6 | Confidentiality, integrity and security of health data | Analyzes repositories and documents supplied by the institution. The institution must control the content it submits. |
The institution must assess the data actually submitted and the processing terms; the platform does not presume uploaded files contain no sensitive data.
What else the sector demands
The CFM resolution is the one with a date on it, but not the only one asking for evidence from whoever builds or runs health software. Below, what each demands and what the platform produces. The right column also says how it arrives: as a ready-made regulation inside the product, or as technical evidence feeding the technical file.
| Regulation | What it demands | What comes out of here |
|---|---|---|
| HIPAA · 45 CFR 164.520 | What the privacy notice must contain: uses and disclosures of health information, individual rights, the entity's duties and how to complain | Point by point review of the notice, citing the paragraphReady-made in the product, 37 criteria |
| ANVISA RDC 657/2022 | Lifecycle and quality evidence for software as a medical device | Code maturity measured and versioned, with history comparable across releasesReady-made in the product, 29 criteria, plus versioned code maturity |
| IEC 62304 · SOUP control | Identify third party software in the device and monitor known anomalies | Continuous dependency inventory with advisories, refreshed on every build instead of frozen in the fileTechnical evidence |
| FDA · section 524B | SBOM and post market vulnerability surveillance | CycloneDX SBOM per repository and continuous CVE monitoring in dependencies and container imageTechnical evidence, exportable |
| ISO 14971 · risk management | A risk management file for the software, kept through the product's life | Risks with severity and business impact, with a remediation trail proven by re-scanTechnical evidence |
| LGPD with sensitive data | Technical safeguards in software that handles patient data | Code security, secrets, infrastructure and dependencies, measured continuouslyReady-made in the product, 40 criteria |
What remains the institution's duty
The platform produces technical evidence; it does not issue a regulatory opinion. These remain with the institution:
- Classifying each system's risk as low, medium, high or unacceptable (Art. 12 and 13, Annex II)
- Create the AI and Telemedicine Committee when the institution adopts its own AI systems (Art. 14, sole paragraph)
- Recording AI use in the patient's medical record (Art. 4, V)
- Informing the patient and honouring an informed refusal (Art. 5 and Art. 11)
- Monitoring clinical bias in the model's outputs (Annex III, II)
We say this in the first conversation, not in the audit. A vendor promising to solve the whole regulation is usually the first one a committee distrusts, and rightly so: the Technical Director answers to the Council, not the vendor.
Where to start
Connect the repositories and the AI providers' admin key. Measurement starts with no rule to configure, and the baseline lands in the first week. In Content Compliance the CFM resolution ships ready as a context: pick the regulation, submit the consent form, the internal policy or the communication material, and get a point by point diagnostic citing the article behind each finding, as a PDF to attach to the file.
Official text of the resolution: Resolution CFM 2.454/2026 (PDF)