Insight · Checklist
AI Systems Integration Checklist
How to use this
This is a pre-production checklist for connecting an AI capability to systems an organization already runs. Eight phases, worked in order, from scoping through handover. Items marked blocking should stop a launch; the rest are advisory and can be accepted as known debt with a recorded reason. Print the page to work through it away from a screen.
58-word direct answer
Key takeaways
- Work the phases in order. Phase two blocks more launches than every other phase combined.
- Blocking items should stop a launch. Advisory items can be accepted as debt, but record the acceptance.
- A “no” that gets discussed is fine. A “no” that gets skipped past is how incidents happen.
- The whole page prints cleanly, with the interface stripped and every answer expanded.
The eight phases
Roughly sequential. Phases three and four interleave in practice, and phase seven should be revisited whenever volume changes materially.
| Phase | Question it settles | Blocking items |
|---|---|---|
| 1 · Scope | Is this a real, repeating workflow with an owner? | 4 |
| 2 · Identity and access | Whose identity does the system act under, and who can revoke it? | 5 |
| 3 · Data handling | What is this data, and what obligations attach to it? | 5 |
| 4 · The integration | Where does output land, and can a retry break something? | 5 |
| 5 · Oversight | Who reviews what, and before what takes effect? | 4 |
| 6 · Observability | Will you notice when it fails, and can you reconstruct a decision? | 4 |
| 7 · Cost | Does the economics hold at real volume? | 2 |
| 8 · Handover | Can someone else run this? | 3 |
32 blocking checks and 20 advisory, 52 in total.
Phase 1 · Scope
Before any technical work. Four blocking, two advisory.
BLOCKING · The workflow is named and repeating
You can describe the trigger, the sequence of steps, the completion condition, and how often it happens. Not a capability or an ambition. A process.
BLOCKING · A process owner is named
A person accountable for this process producing correct results, whose role includes it. Not the person most enthusiastic about AI, and not “the IT team”.
BLOCKING · A baseline is captured
Cycle time, volume, error or rework rate, or cost per unit, measured before anything changes. It cannot be reconstructed later.
BLOCKING · The failure consequence is described and recoverable
You can state what happens if the output is wrong, and it does not cause irreversible harm to a person, a payment, or an eligibility decision.
ADVISORY · The real process is documented, not the official one
Including the workarounds and the shared spreadsheet nobody mentions. Automating the documented process instead of the real one automates a fiction.
ADVISORY · An adjacent second workflow is identified
Knowing what this integration might be extended to shapes how generally to build it, without over-building for it now.
Phase 2 · Identity and access
Start this on day one. It is the phase with an external dependency and the one that most often adds weeks. Five blocking, two advisory.
BLOCKING · The workflow runs under a service identity, not a person
An integration on an individual's credentials inherits everything that person can see, breaks when they change role, and makes the audit trail meaningless.
BLOCKING · Scopes are least-privilege
The identity can read and write only what the workflow needs. Broad requests attract scrutiny that narrow ones do not; scoping tightly often unblocks a stalled approval.
BLOCKING · The client owns every account
Not the consultant, not the agency. Continuity should sit with the organization, so an engagement ending never puts a workflow at risk.
BLOCKING · Access is revocable without a support ticket
Someone inside the organization can remove third-party access immediately and unilaterally.
BLOCKING · The access decision-maker is identified by name
The person who can actually approve this, not the team that theoretically owns it. Unowned access decisions are the single most common cause of a stalled integration.
ADVISORY · An access review date is set
Scopes widen during troubleshooting and are rarely narrowed again. A scheduled review catches the drift.
ADVISORY · Credential rotation is possible without downtime
You know how to rotate a key and roughly what it costs in interruption.
Phase 3 · Data handling
Classify before selecting a tool, not after. Five blocking, three advisory.
BLOCKING · The data is classified
You know what the workflow reads and writes, and what category it falls into: public, internal, confidential, or regulated.
BLOCKING · Obligations attached to that data are identified
Donor records, student records, health information, and client confidential material each carry constraints that may rule out a provider or require a specific contractual posture.
BLOCKING · The provider's retention terms are documented
Whether prompts and outputs are retained, for how long, and by whom. Recorded, not assumed from a marketing page.
BLOCKING · The provider's training-use position is documented
Whether your content can be used to improve their models, and whether that is configurable on your plan.
BLOCKING · No prohibited data enters the workflow
A specific, written statement of what must never be sent, and a mechanism, not just an instruction to staff.
ADVISORY · Data residency is understood
Where processing physically happens, if that matters to your obligations or your clients' expectations.
ADVISORY · Subprocessors are known
Who else touches the data behind your chosen provider.
ADVISORY · A deletion path exists
You could remove a specific record from the workflow's reach on request.
Phase 4 · The integration
The engineering. Five blocking, three advisory.
BLOCKING · A supported interface is used
A documented API, not a screen layout or an undocumented endpoint. Where none exists, treat the integration as temporary infrastructure and monitor it accordingly.
BLOCKING · The write path is specific
Output lands in a named field on a named record type, not in a chat window that a person then copies from.
BLOCKING · Writes are idempotent
A retry after a transient error cannot create a second record. Unglamorous, and it prevents a whole category of embarrassing data problems.
BLOCKING · An evaluation set of real cases exists
Thirty to fifty historical cases with known good outcomes, deliberately including the awkward ones. This becomes the regression check for every later change.
BLOCKING · Awkward inputs are handled explicitly
Forwarded threads, scanned attachments, missing fields, other languages. Handled or explicitly rejected. Never silently mis-parsed.
ADVISORY · Model and version are pinned and recorded
So a change in behavior can be attributed rather than guessed at.
ADVISORY · The prompt or configuration is in version control
Treated as code, with a history, not pasted into a tool's settings field.
ADVISORY · Rate limits and backoff are handled
The workflow degrades rather than failing hard when a provider throttles it.
Phase 5 · Oversight
Sized to consequence, not applied uniformly. Four blocking, two advisory.
BLOCKING · A risk tier is assigned and written down
Low, moderate, or high, with the reasoning. An unwritten tier is not a decision.
BLOCKING · The review point matches the tier
Internal drafting: spot check. Client-facing: named reviewer before release. Affecting money, eligibility, or a person's standing: a person decides and the system is advisory only.
BLOCKING · A named reviewer exists, with a named backup
A role, not a rota nobody maintains. A single reviewer on leave should not stop the workflow or cause the review to be skipped.
BLOCKING · Staff know what they are permitted to release
Ambiguity produces either over-checking, which removes the benefit, or under-checking, which eventually produces an incident.
ADVISORY · A re-approval trigger is defined
What change of scope would require the tier and review point to be reconsidered. A workflow approved for internal drafting can drift into client-facing use.
ADVISORY · Citations to source are available where accuracy matters
For retrieval workflows, so a reviewer can check rather than trust.
Phase 6 · Observability
Four blocking, three advisory. The silent-stop check is the one teams most regret skipping.
BLOCKING · Failures alert a named person
Not a shared inbox nobody reads, and not a dashboard nobody opens.
BLOCKING · Silent stops are detected
An integration that simply stops running is invisible, because success was also quiet. Alert on absence of expected volume, not only on errors.
BLOCKING · A single decision can be reconstructed
Input, retrieved context, model and version, output, approver, timestamp. This is what makes an incident investigable rather than speculative.
BLOCKING · A rollback path is documented
How to disable the workflow and resume the prior process without data loss. Written down, not held in someone's head.
ADVISORY · Override rate is tracked
How often a reviewer materially changes the output, and whether it is trending down. A rate that never falls means the workflow is not yet right.
ADVISORY · Volume and latency are tracked
So degradation is visible before someone complains.
ADVISORY · Log retention is bounded
Logs containing input data are themselves subject to the phase-three obligations.
Phase 7 · Cost
Two blocking, two advisory.
BLOCKING · Cost per unit is modeled at realistic volume
Not at test volume. Retrieval over large documents in particular behaves very differently at production scale.
BLOCKING · A spend alert exists
A threshold that notifies someone before an invoice does.
ADVISORY · The cost of the current manual process is known
Otherwise there is nothing to compare the new cost against, and phase one's baseline is incomplete.
ADVISORY · A cheaper model has been tested for the task
Many production workflows run acceptably on a smaller model. Testing this is usually a short exercise with a material result.
Phase 8 · Handover
Three blocking, three advisory. This phase is what separates a workflow from a dependency.
BLOCKING · A second person can operate it
Someone other than the builder can run it, explain what it does, and knows what to do when it is wrong.
BLOCKING · Documentation is written for a successor
Enough that someone who has never seen it could take it over, not notes that make sense only to the author.
BLOCKING · A review cadence is set with an owner
When this gets looked at again, and by whom. Without it, drift is invisible until it is a problem.
ADVISORY · The evaluation set is retained and re-runnable
So a future change can be regression-checked rather than hoped about.
ADVISORY · Known limitations are written down
What this workflow does badly, so the next person does not rediscover it through an incident.
ADVISORY · A deliberate retirement path is described
What would cause you to switch this off, and how. A documented retirement is a legitimate outcome.
First-hand experience
Which checks actually catch things
Across engagements, three items on this list have caught more problems than the rest combined, and none of them is technically interesting.
Phase 2, the named access decision-maker. Teams routinely know which team owns access and not which person can approve it. The gap between those two facts is where weeks disappear.
Phase 6, silent-stop detection. Integrations do not usually fail loudly; they stop. Because success was invisible, so is the absence of it. Discovering a workflow stopped six weeks ago is a specific and avoidable kind of embarrassment.
Phase 4, awkward inputs. Pilot examples are curated by the person who wants the pilot to succeed, not dishonestly, just naturally. The forwarded email thread and the record with three empty fields are where production actually lives.
On accepting an advisory item as debt
Advisory items can be skipped. The discipline is recording that you skipped them and why, so the decision is visible to whoever inherits the workflow.
A one-line note against the item is enough: what was accepted, who accepted it, and what would make it worth revisiting. Undocumented debt is indistinguishable from an oversight six months later.
Limitations of this checklist
This is written for internal operational workflows in organizations running commercial business systems, without a dedicated platform-engineering function. It does not cover shipping an AI feature in a product you sell, model training or fine-tuning infrastructure, real-time or safety-critical control systems, or deployments where a named regulatory regime dictates the architecture.
It is a practitioner checklist, not a compliance instrument. Passing every item does not establish compliance with any standard, and nothing here constitutes legal, privacy, or security advice. A deployment touching regulated data needs review by qualified practitioners; see responsible AI governance and AI data practices.
The blocking-versus-advisory split is a judgment, not a standard. Your risk posture may reasonably promote an advisory item to blocking, and a genuinely low-stakes internal workflow may reasonably demote one. What is not defensible is skipping an item without noticing.
Fifty-two items will look like a lot for a small workflow. Most are quick: the majority are questions with an existing answer somebody just has to state out loud.
External references
Useful alongside this checklist for the governance and risk dimensions.
Using and citing this checklist
Free to use, adapt, and circulate internally. If you publish an adapted version, attribution to martinzialcita.com is appreciated and a note on what you changed is more useful to your readers than fidelity.
To cite: Zialcita, M. (2026). AI Systems Integration Checklist. martinzialcita.com. https://martinzialcita.com/insights/ai-systems-integration-checklist/
This page prints cleanly: navigation, calls to action, and interface elements drop away, and every collapsed answer expands, so the printed copy is complete.
Frequently asked questions
Is 52 checks realistic for a small workflow?
Most items are questions with an answer someone already knows and has not stated. Working through the list for a straightforward workflow typically takes a couple of hours, not weeks.
The ones that take real time are phase two access provisioning and phase four's evaluation set. Both are worth the time, and both are cheaper before launch than after.
Can we launch with blocking items unmet?
You can, and organizations do. The point of the label is that doing so should be an explicit, recorded decision by someone with the authority to accept the consequence, not something that happens because nobody checked.
The blocking items that most commonly cause real harm when skipped are the phase five review point and the phase six reconstructability check.
How does this relate to the checklist on the systems integration page?
The AI systems integration page carries a twelve-item summary for readers who want the shape of it. This is the full phased version that summary condenses.
Use the short one to sanity-check a plan; use this one before you launch.
Does passing this mean the integration is safe?
No. It means the common operational failures have been considered. Safety depends on your specific data, your risk posture, and your obligations, none of which a generic checklist can assess.
Treat a completed checklist as evidence that the work was done attentively, not as a certificate.