Checklist: How to Tell Whether a Task Is Ready to Be Automated with AI

Automating a task with artificial intelligence (AI) does not start with choosing a tool, but with checking whether the process can be delegated in a controlled way. A preliminary assessment helps avoid projects that do not address a clear problem, depend on unsuitable data, or lack mechanisms to detect and correct errors.

The following checklist is intended for executives and operations managers. It is an assessment guide, not a certification or a substitute for applicable legal obligations. The rules depend, among other factors, on the territory, intended use, data processed, and people affected.

1. Define the objective and set the scope of the task

• What specific problem are you trying to solve? Describe the expected outcome, such as classifying requests, extracting information from documents, or preparing a draft for review.
• Which part of the process will be automated, and which part will remain in a person’s hands? Define inputs, outputs, exceptions, and decisions the AI must not make.
• Is there a measure for comparing results? Define how quality, time, cost, and other relevant indicators will be observed before testing the system.
• Has a simpler alternative been considered? An automated rule, a workflow improvement, or a conventional tool may be sufficient.

If the objective cannot be clearly expressed, it will be difficult to determine whether AI performs better than the current process or adds value.

2. Check the data before assessing the model

• Is the necessary data available, and can it be used for this purpose? Review its source, permissions, contractual restrictions, and access conditions.
• Is it relevant, sufficiently complete, and up to date? Identify duplicates, errors, gaps, and foreseeable changes in the data.
• Does it contain personal, confidential, or sensitive information? Determine what information is entered, who can access it, where it is processed, and how long it is retained.
• Is the data journey known? Document what information goes in and out, and which providers or systems are involved.
• Does the provider explain the system’s limitations and how it uses the data? If there is insufficient information to assess these aspects, record them as an outstanding uncertainty.

Technical availability does not mean that the data is authorized for any use. Privacy, security, intellectual property, and retention issues must be reviewed on a case-by-case basis and according to the applicable jurisdiction.

3. Compare performance with the current process

• Has the system been tested on examples representative of actual work? Include common cases, exceptions, and difficult situations.
• Were acceptance criteria defined before the test? For example, which types of errors are tolerable and which require the process to be stopped or reviewed.
• Is more than speed being assessed? Consider accuracy, consistency, robustness to different inputs, and performance across relevant groups or situations.
• Are the limits of the evaluation understood? A good result on a test sample does not guarantee the same performance in other contexts or after changes to the data or system.

Compare AI with the current alternative using equivalent criteria. If it does not improve an important outcome or introduces errors that are difficult to detect, automation may not be justified.

4. Measure the consequences of an error

• Who could be affected by an incorrect output? Identify customers, employees, suppliers, or other people connected to the process.
• What operational, financial, reputational, or personal harm could the error cause? Distinguish between an output that can be corrected easily and one that triggers a decision that is difficult to reverse.
• What decisions depend on the result? Clarify whether the AI provides information, prioritizes cases, or influences a final decision.
• Is there a way to challenge or correct the result? Determine how outputs are reviewed and how complaints or incidents are handled.

The greater the potential consequences, the more robust the assessment and the more direct the oversight should be. If it is not possible to identify who is affected by the system or how to remedy a failure, those shortcomings should be addressed before deployment.

5. Assign responsibility and establish human oversight

• Is someone responsible for the system and the process? It should be clear who authorizes its use, who operates it, and who makes decisions when an incident occurs.
• Does the person overseeing it have the information and ability to intervene? Human review must allow people to detect, correct, or escalate results, rather than simply approve them automatically.
• Are situations requiring mandatory review defined? For example, uncertain results, cases outside the specified criteria, or decisions with significant effects.
• Does staff understand the limitations and permitted uses? Provide appropriate instructions and training for those who use or review the system.

Oversight should be proportionate to the level of impact. For a low-risk task, sample-based review may be sufficient; for higher-impact processes, every relevant result may need to be verified before action is taken.

6. Review risks and applicable requirements

• Have privacy, security, bias, misuse, and systematic error risks been identified? Also record the measures that reduce each risk and any aspects that remain unresolved.
• Have the provider’s terms been reviewed? Check responsibilities, data access, service changes, incident notification, and options for ending the relationship.
• Are the applicable legal obligations known? The answer depends on the territory and the specific use. Before deployment, determine whether rules on data protection, employment, consumer protection, safety, or other areas apply.
• Have the purpose, decisions, and control measures been documented? Keep sufficient records to explain how the system was assessed and authorized.

The NIST AI Risk Management Framework offers guidance for addressing trust and AI risks. The reporting framework of the G7 Hiroshima Process (HAIP), promoted by the OECD, allows participating organizations to report risk management practices voluntarily. According to the information available, the OECD Secretariat checks that responses and supporting materials are present and accessible, but does not verify the substantive content of the statements. Participating in or appearing in that framework does not amount to certification or endorsement of an organization’s practices.

Therefore, these references can help structure an assessment, but they do not replace a review of the binding rules that apply. Obligations cannot be inferred solely from the adoption of voluntary guidance.

7. Calculate total cost and expected value

• Have integration, licensing, and usage costs been included? Add infrastructure, storage, and any external services.
• Has the work needed to review and correct results been estimated? Oversight, exception handling, and process updates also consume resources.
• Are security, training, auditing, and maintenance included? Do not limit the calculation to the tool’s initial cost.
• Can the expected benefit be measured against these costs? Consider time savings, released capacity, or quality improvements without assuming they will materialize.

Automation may speed up one stage while shifting work to review or error handling. The assessment should cover the entire process.

8. Test in a controlled way and prepare for monitoring

• Will you start with a limited test? Define its scope, duration or completion conditions, responsible people, and criteria for deciding whether to continue.
• Will performance be monitored after deployment? Establish indicators, reviews, and alerts to detect changes, failures, or uses outside the intended scope.
• Is there an incident procedure? Determine how to record, escalate, and correct problems, and when to pause the system.
• Will the assessment be reopened if the model, data, or process changes? Initial approval does not automatically cover subsequent changes.
• Are there clear conditions for expanding, adjusting, or withdrawing the solution? The decision to scale should be based on observed results and controlled risks.

Final decision: proceed, adjust, or postpone

Proceed with a limited test if the objective and criteria are defined, the data and permissions have been reviewed, someone is responsible, and oversight and incident mechanisms are in place.

Adjust the design if the use case seems viable, but controls, representative data, training, or clarity about responsibilities are lacking.

Postpone deployment if it is not possible to assess the consequences of errors, protect the data, assist the people affected, or meet applicable requirements. The decision to automate is not merely technical: it requires being able to explain what the system does, who is accountable for its use, and what will be done when it fails.