What are the signs that an organisation may struggle to comply with new rules on automated decision-making?

How noncompliance shows up before the policy change lands

The warning signs usually appear in operating model gaps, not in the legal text itself. If the organisation cannot produce a reliable inventory of automated decision-making, cannot show where human intervention occurs, or cannot trace which business rule produced a specific outcome, it will struggle to prove compliance once the new rules are enforced.

Those gaps matter because compliance depends on evidence, not intent. When decisioning is distributed across product teams, vendors, scripts, and legacy workflows, accountability becomes fragmented and the organisation loses the ability to demonstrate control over the decision path.

Operational signs that the organisation is not ready

One clear sign is inconsistent ownership. If no team can answer who approves the model or ruleset, who reviews exceptions, and who is responsible when an individual challenges a decision, the governance structure is already too weak for a regulated automated-decision process.

Another sign is poor decision traceability. Teams should be able to explain what data was used, what logic was applied, what human review was possible, and what outcome was returned. When that chain is incomplete, the organisation may be unable to satisfy accountability, fairness, or explanation requirements.

A third sign is that the control design is still manual, ad hoc, or local to one function. If safeguards depend on individual analysts remembering to intervene, or if the logic differs by region, product, or channel without central oversight, compliance will be inconsistent and difficult to evidence at scale.

Legacy workflow dependence is also a strong indicator. Older case management, approval, and rules engines often hide where automation starts and stops, so the organisation may not even know whether a decision is fully automated, partially assisted, or reviewed after the fact.

What usually breaks first when scrutiny increases

The first failure is typically documentation. Many organisations have decision logic in code, vendor settings, spreadsheets, and policy memos, but no single, current record that links the decision purpose, the inputs, the review step, and the challenge process. That makes internal audit and regulatory response slow and uncertain.

The second failure is exception handling. If the business cannot show how edge cases are escalated, overridden, or reopened, then the control may exist in theory but not in practice. That is especially risky when automated outcomes affect access, eligibility, pricing, or other material decisions.

The third failure is testing and monitoring. If teams are not routinely checking whether the automated process still behaves as intended, control drift can build quietly. Small changes in data, vendor logic, or workflow routing can erode compliance without any obvious incident.

Risk and Threat Considerations

The main risk is that an organisation will believe it has safeguards because a policy exists, while the actual operating process cannot support them. In automated decision-making, that gap creates exposure to regulatory challenge, customer complaint escalation, and avoidable remediation work.

Failure mechanism: Decision logic, review paths, and challenge rights are dispersed across systems and teams, so the organisation cannot reconstruct or defend the full decision lifecycle when asked.

Impact: The organisation may be unable to prove lawful processing, explain outcomes, or demonstrate meaningful human oversight, which increases the likelihood of enforcement, customer dispute, and forced process redesign.

Practitioner Guidance

What to verify: Confirm that every automated or partially automated decision has an owner, a documented logic source, a named review point, and a customer challenge path. If any of those elements cannot be evidenced end to end, treat readiness as incomplete.

What to prioritise: Start with the highest-impact decision flows, especially those that affect eligibility, access, financial terms, or adverse outcomes. Those are the workflows most likely to be tested first and the hardest to defend after the fact.

Common mistake: Treating policy publication as compliance. A readable policy is useful, but it does not substitute for traceable decision logic, operational review, and a demonstrable appeal or correction process.

Practitioner takeaway: The strongest early signal of trouble is not that the rules are unclear, but that the organisation cannot prove how automation is governed in practice, decision by decision.

Related resources from NHI Mgmt Group

• What are the signs that an automated employment decision tool may not be compliant with bias audit rules?
• What are the signs that a company is not ready to comply with new data access and sharing rules?
• What do privacy programmes get wrong about automated decision-making?
• Who is accountable when automated decision-making disclosures are incomplete?