AI Automation Planning: Define the Task Before the Tool

Beschreiben Sie die Aufgabe genau.

Beginnen Sie mit einer wiederholbaren Aktivität. Notieren Sie die Eingaben, erwarteten Ausgaben, Ausnahmen und die für das Ergebnis verantwortliche Person. Wenn die Aufgabe nicht klar beschrieben werden kann, nehmen Sie sich Zeit, sie zu verstehen, bevor Sie sich für eine Automatisierungsmethode entscheiden. Einige Anforderungen passen möglicherweise besser zu einfachen Regeln als ein KI-basierter Ansatz.

Definieren Sie, wie ein nützliches Ergebnis aussieht.

Erstellen Sie repräsentative Beispiele, die das Team überprüfen kann. Beziehen Sie auch unangenehme Fälle, unvollständige Eingaben und Situationen ein, die an eine Person eskaliert werden sollten. Vereinbaren Sie, wie die Ergebnisse bewertet werden, bevor Sie den Arbeitsablauf erweitern. Die Bewertung sollte die tatsächliche Aufgabe widerspiegeln und nicht eine beeindruckende, aber nicht damit zusammenhängende Demonstration.

Halten Sie die Überprüfung und den Zugriff explizit.

Entscheiden Sie, welche Ausgaben eine menschliche Genehmigung erfordern und auf welche Informationen der Workflow zugreifen kann. Besprechen Sie die Fehlerbehandlung und den Weg zur Korrektur einer Ausgabe. Vermeiden Sie es, während eines Prototyps einen umfassenderen Zugriff zu gewähren, nur weil dies praktisch ist. Die Verantwortung für die endgültige Entscheidung sollte sichtbar bleiben.

Überprüfen Sie das Pilotprojekt, bevor Sie es erweitern.

Vergleichen Sie das Pilotprojekt mit dem aktuellen Workflow anhand der von Ihnen vereinbarten Kriterien. Notieren Sie Einschränkungen und offene Fragen. Eine umfassendere Einführung ist eine separate Entscheidung, die auf den Ergebnissen des Pilotprojekts, den Betriebsanforderungen und den Personen basiert, die es unterstützen werden.

Scope the pilot before selecting a tool

Choose one task with a clear start and finish. Observe how a person handles it today, including the checks they perform before acting. Identify whether the proposed automation prepares information, recommends a decision or performs an action; these require different review boundaries.

Build a small, representative evaluation set with agreed expected outcomes. Test incomplete inputs, ambiguous requests and cases outside the intended scope. Record incorrect outputs and the work needed to correct them. Compare the pilot with the existing process using the same task definition, then decide whether to revise, expand or stop. Keep any production rollout separate from the initial experiment.

A one-page automation opportunity sheet

Complete this sheet with the person doing the task and the person who would operate the automation. It should expose uncertainty before a technical demonstration.

• Task boundary: trigger, required inputs, intended output and actions the automation must never take.
• Current process: responsible role, checks, common exceptions and existing escalation routes.
• Candidate method: simple rules, assisted drafting or another approach, with the reason for considering it.
• Evaluation: representative cases, unacceptable errors and the person reviewing each result.
• Operating plan: access, monitoring, fallback, correction ownership and expected running costs.
• Decision gate: evidence needed to continue, revise the scope or end the pilot.

Avoid automating an unclear decision

If staff disagree about the correct outcome, resolve the rule or policy before asking a tool to reproduce it. A model cannot settle an unowned business decision merely by generating a confident answer.

Do not assess only successful outputs. Review incorrect actions, uncertain cases and time spent checking results. Keep access restricted to the information needed for the pilot, and avoid presenting a prototype demonstration as evidence that the wider workflow is ready to operate without supervision.

Does automation always need AI?

No. A stable task with explicit conditions may be better served by rules or an ordinary software workflow. Consider AI where the task warrants evaluation, and compare it against a simpler baseline rather than assuming the more complex option is preferable.

ILLUSTRATIVE PLANNING EXAMPLE

Example: routing incoming support requests

A support team wants to route enquiries by subject. Define the available categories and give the pilot a representative set of anonymized messages. Include messages covering two topics and requests that do not fit any category. Decide which uncertain results return to a person rather than moving straight into a queue.

Record the routing decision, reviewer correction and reason for escalation. Use that evidence to decide whether to adjust the task, change the method or stop the pilot.

FURTHER READING

Official resources to explore

Explore the related official guidance below. The templates and examples are practical starting points to adapt to your own project.

• NIST AI Risk Management Framework Playbook