AI automation pilot timeline: what two weeks actually covers

How long should an AI automation pilot take?

An AI automation pilot can take 10 business days when one workflow is already build-ready. That means the scope, baseline, owner, data path, access, test cases, and decision rights are settled before the clock starts. Zyphh's Custom Build option uses this narrow delivery cadence for an app, portal, agent, or automation with a defined boundary.

Two weeks is not a credible end-to-end estimate when discovery, data repair, procurement, security review, several integrations, user training, or production rollout still sit inside the word pilot. In those cases, schedule the prerequisite work separately. A short build window should make the boundary clearer, not hide work before or after it.

Why is there no single industry timeline benchmark?

No authoritative source reviewed sets one standard duration for an AI pilot. The Australian Government's AI transition guidance separates proof of concept, pilot, and production by purpose, users, data, integration, governance, and risk. It describes a pilot as limited real-world use with a specified timeframe, not a fixed number of days.

Published timeline claims become misleading when they start and stop at different events. One estimate may measure coding time. Another may include discovery, approvals, observation, and production hardening. Compare scope before comparing duration.

What do useful planning bands look like?

A useful benchmark adjusts for readiness and scope instead of copying a market average. The bands below are Zyphh planning estimates derived from the work that must be completed. They are not survey statistics. A team should replace them with its own estimates once owners inspect the workflow, data, systems, and approvals.

The right band can still move. A dependency may fail, or early evidence may show that a smaller design is safer. The schedule is a decision tool, not a reason to keep building after the assumptions break.

Can your workflow fit a two-week pilot?

Score seven readiness conditions before booking a 10-day delivery window. This worksheet is an illustrative planning device, not a validated maturity model. Give each condition zero points when it is settled, one when a named owner can finish it quickly, and two when it is unresolved or depends on an outside decision.

What fits inside 10 business days?

A 10-day pilot should create an inspectable decision trail for one workflow. It should not produce ten disconnected demos. Each block below ends with evidence the workflow owner can examine, while requests that change the outcome, users, systems, or authority return to the backlog.

NIST's AI RMF Core calls for documented, repeatable testing and measurement under conditions similar to deployment. OpenAI's evaluation guidance likewise recommends task-specific tests, representative data, logging, human feedback, and continued evaluation. A polished happy path alone does not complete the pilot.

What usually adds time to an AI pilot?

Data, authority, and integration work usually add more schedule risk than the model call itself. The Australian Government's AI assurance guidance asks pilot owners to define scope, duration, objectives, measures, participants, consent, and risk controls. Each missing decision creates work that a coding estimate will miss.

• Unstable workflow: Rules change during the build, so the team cannot hold the acceptance target steady.
• Weak data path: Records lack stable identifiers, usable history, representative edge cases, or approved retention.
• Broad authority: The system can send, change, delete, approve, or publish without a narrow permission and review design.
• Several dependencies: Each CRM, billing, support, identity, and warehouse connection adds failure and recovery cases.
• No operating window: The team cannot observe enough real volume or user behavior to answer the pilot question.

OWASP's Excessive Agency guidance recommends minimum tools, minimum permissions, downstream authorization, and human approval for high-impact actions. Those controls can lengthen preparation. Removing them to protect a date only makes the date less credible.

How should you set the pilot clock and decision gate?

Start the clock at a named event and end it at a named decision. This keeps a 10-day build from being presented as a complete implementation. The project brief should also identify who can pause the work when evidence or controls are missing.

1. Name the start: Scope, baseline, owner, data, access, and acceptance rules are approved.
2. Name the finish: The limited-use evidence is ready for a go, fix, or stop review.
3. Measure one business result: Pair it with quality, human effort, exceptions, reliability, cost, and recovery evidence.
4. Set extension rules: Add time only for a specific fault with an owner, test, and review date.
5. Keep production separate: Expansion requires its own authority, support, monitoring, and lifecycle cost decision.

The pilot date is useful only when missing it reveals something. It may reveal an unrealistic scope, an unresolved dependency, or a weak owner. Quietly moving the date while widening the build teaches the team very little.

When should you extend, pause, or stop?

Extend a pilot only when more time can answer a precise question. Pause when a prerequisite or approval is unavailable. Stop when the evidence rejects the approach or the expected value no longer justifies the operating cost and risk.

Before expansion, review the AI automation guardrails for permissions, approvals, logs, stop rules, and recovery. The next useful step is to score one real workflow, separate prerequisite time from delivery time, and ask whether the proposed pilot can produce a decision rather than a demo.