Decide where the workflow starts and stops

Budgets get vague fast when the thing you're costing is just "the AI". I'd start by naming the trigger that kicks the work off and the state you can actually see when it's finished, then include every handoff in between.

Say you've got a document review workflow. The trigger might be an authorised user submitting a supported file. Finished might mean the extracted fields have been checked, accepted into the system of record and made available to whatever process comes next. The model call is one step somewhere in the middle.

I'd write the path out in plain language:

1. A request comes in and we check identity and permission.
2. The source material is accepted, scanned and normalised.
3. The relevant context is retrieved.
4. The model proposes an output or an action.
5. Deterministic validation runs.
6. A person reviews the cases that need judgement.
7. Accepted results update the system they're meant to update.
8. The user gets a status and a way to ask for a correction.
9. Logs, evidence and temporary data follow the retention rules.

Then add branches for the failures you already know you'll have to deal with: unsupported input, missing context, a provider timeout, malformed output, a rejected recommendation, a duplicate request, and an external system that's down after something has already been approved.

If output quality depends on upstream source material, that maintenance belongs inside the boundary too. A retrieval workflow sitting on top of policies and procedures uses up editorial effort every time those documents change. Write that work down even if another team is paying for it, or your estimate will come up short.

You also need a unit of work. It could be a case, a document, a conversation, a decision or a completed action. Pick something you can count at both the trigger and the completion point. If one case can create several model calls, retries and a review task, "API call" is a bad business unit.