SMACTR Internal Algorithmic Audit
Description
SMACTR is an internal audit procedure for AI systems, proposed by Raji and colleagues in 2020, in which an audit team inside the developing organisation but separate from the product team examines a system during development and before launch against the ethical objectives and requirements the organisation has declared for it. The audit runs in five stages, each producing set documents. In Scoping, auditors review the product requirements and the declared objectives and write an ethical review of the use case, drawing in independent domain experts and marginalised groups, and a social impact assessment; in Mapping, they map the people involved, review existing design records, interview the engineers and begin a failure modes and effects analysis (FMEA), a systematic review of the foreseeable ways the system could fail and their effects, used to rank risks for testing. In Artefact Collection, a checklist confirms that the expected development documents, such as model cards and datasheets, exist; in Testing, auditors run tests chosen from the FMEA's priorities, such as adversarial probing with tailored inputs, and rate each risk high, mid or low from its likelihood and severity in an ethical risk analysis chart; in Reflection, they set the results against the declared objectives, finalise the risk analysis and agree a remediation plan with the engineering team. The documents are kept in an algorithmic design history file, from which the auditors write a summary report that leadership can use to decide whether the system launches, changes or is abandoned.
Example Use Cases
General
An insurer's internal audit team audits a claims-triage model before launch. Interviews in Mapping reveal that a field used as a proxy for chronic illness was dropped late without the requirements being updated; the FMEA ranks under-prioritising complex claims as the top risk, so Testing concentrates on claims from people with several conditions, and the summary report goes to the risk committee with a remediation plan and a recommendation to delay launch.
A software company's responsible-AI audit team audits a customer-support chatbot. Artefact Collection finds no datasheet for the fine-tuning conversations, so the auditors require the product team to write one before testing; prompts drawn from the FMEA then test whether the bot discloses other customers' account details or gives poorer answers to customers writing in non-standard English, and the ethical risk chart and remediation plan record what must change before release.
A government digital service's audit team, which reports to the agency's chief risk officer rather than to the delivery programme, audits an in-house model that prioritises housing repair requests before it replaces manual triage. The chief risk officer uses the summary report to decide whether the model goes live, and the design history file and report are filed where the agency's external auditors and ombudsman can later inspect them.
Limitations
- The auditors are employees of the organisation they audit and share its interests; the authors acknowledge that independence is hard to keep and that audits risk becoming reputation management. Findings carry more weight when the audit team reports outside the product's management line and the design history file can be examined by an outside party.
- The system is judged against the ethical objectives the organisation declares for it, which the authors note have been criticised as vague, and the paper leaves open what level of performance, for example how close to parity across groups, counts as acceptable. A clean audit shows consistency with the standards and thresholds the organisation chose to declare, and says nothing about any external standard it did not adopt.
- The Testing stage prescribes no particular tests; the authors expect tests to vary widely by system and to follow the FMEA's priorities. What the audit can show about the system's behaviour therefore depends on the tests the team chooses, and a failure mode the FMEA did not foresee is likely to go untested.
- The audit is deliberately slow and document-heavy, and the authors note that fast, iterative development is hard to audit. Its results describe the system at the time of the audit, so a model retrained or reconfigured afterwards is not covered unless the relevant stages are repeated.
- The paper does not say which systems should be audited or in how much depth, leaving that to the organisation, and it illustrates the procedure only on two hypothetical client projects. Published evidence of how well it finds problems in real systems is limited.