Frequently asked questions

Plan for a sponsor who can resolve priorities, a delivery contact, and people who understand the affected process and systems. Agree their involvement at discovery, design review, testing, and handover rather than assuming they are available throughout. Reserve decision dates and name deputies. If essential people cannot participate, reduce the scope or move the milestone; a consulting engagement does not remove the need for internal decisions.

Record the requested change and its effect on deliverables, dependencies, risk, cost, and timing before starting the additional work. The sponsor should choose whether to exchange priorities, approve a revised scope, or defer the request. Keep the original acceptance criteria unless explicitly changed. If a prerequisite is late, agree what can continue safely and what must pause rather than silently compressing testing or handover.

Assign a purchasing owner and confirm which costs are included in the engagement before approving work. Separate consulting fees from subscriptions, usage charges, third-party services, and ongoing operating costs. Confirm purchasing authority, contract ownership, renewal dates, and a budget for trials that might become production services. A technical recommendation is not a purchase authorization, and a successful trial does not confirm production licensing or contractual rights.

Agree who designs, approves, implements, and supports each change, including work that crosses supplier boundaries. Use your established change process, with named contacts, an approved implementation window, a rollback owner, and evidence of completion. Confirm any restrictions in existing support contracts before modifying a managed environment. Record unresolved dependencies in a shared decision log so neither provider assumes the other has accepted responsibility.

Define observable acceptance criteria and a named customer approver before delivery begins. Review the agreed outputs against those criteria, including unsuccessful paths, documentation, and operational readiness where relevant. Record defects separately from new requests, with an owner and decision for each. A walkthrough or lack of feedback should not be treated as approval; the acceptance process and any outstanding conditions belong in the agreed engagement terms.

Agree the handover package during scoping: configuration and design records, operating instructions, known limitations, unresolved risks, and ownership of project artifacts. Have the receiving team walk through a routine change and a failure scenario, then review and remove temporary project access. Ongoing optimization, monitoring, service hours, and incident response require a separate explicit scope; they are not implied by completing a project. This website is not an emergency response channel.

Measure the current process first, then compare equivalent work with AI assistance. Include review time, corrections, exceptions, training, licensing, usage, and support costs. Distinguish time released for other work from cash savings that require an actual budget change. Have the process owner confirm whether quality, throughput, or customer outcomes improved; activity counts and generated content alone do not demonstrate value.

Agree stop criteria before the pilot begins, alongside the measures of success. Examples include unauthorized disclosure, an action outside the approved scope, review effort that removes the expected benefit, or no team willing to own the service. A serious safety issue should pause the affected activity even if average results look good. Record whether to remediate and retest, narrow the use case, or retire it, including how trial access and retained data will be handled.

Use the organization's established risk authority, not the delivery team or the AI system itself. An exception record should name the accountable owner, affected use, reason, remaining risk, compensating controls, expiry date, and review triggers. Security, privacy, and legal stakeholders should review issues within their remit. A business sign-off cannot override a legal obligation, and an exception should not silently become permanent when a pilot enters production.

Provide a clear reporting route and distinguish requests for a useful capability from a suspected information exposure. Identify the tasks, information shared, connected accounts, and any retained data without asking people to copy sensitive prompts into an ordinary ticket. Route possible exposures through the existing incident process. Offer an approved alternative where practical, explain prohibited uses, and set a review date for outstanding requests so a blanket warning is not the only response.

Define a timeout, an authorized deputy, and a safe pending or rejected state before enabling the workflow. Approval-required actions should not proceed because a queue is old or a reviewer is absent. If the underlying request changes while waiting, require fresh review. Make the queue visible to its operational owner and document a manual route for urgent work that preserves the same authority and evidence requirements.

For decisions that affect people or customers, establish a route to a human reviewer with authority to correct the outcome. Explain what information is needed to raise a concern, who handles it, and how the decision and correction will be recorded. Preserve relevant evidence under approved access and retention rules without retaining every prompt indefinitely. Have legal and privacy stakeholders determine applicable notice and review obligations; a generic AI disclaimer is not a substitute.

Assign someone to track supplier notices, retirement dates, and material changes to terms or data handling. Keep a record of the version and configuration last approved, where the service exposes them. Reassess affected workflows before accepting changed behavior, including output quality, permissions, cost, and recovery. Where versions cannot be pinned or rolled back, define a manual fallback or a way to suspend the affected capability rather than assuming the supplier can restore it.

Use the established incident route and have an authorized operator pause the affected workflow or revoke its ability to act. Preserve relevant action records, identify downstream changes, and involve the owners of affected systems before attempting reversal. Avoid replaying the same request while the cause is unknown. Resume only after an accountable owner reviews the cause, corrective controls, and retest evidence; treat notification obligations as a decision for the appropriate legal and privacy stakeholders.