WikiQuestions to ask before deploying in an enterprise environment

Questions to ask before deploying in an enterprise environment

Section 06 of 07Last reviewed 25 October 2026Applies to Any AI coding assistant

Ten groups of questions. Each one has an owner and an answer that can be written down. If several answers are “unknown”, that is the first piece of work, before any tool is rolled out.

1. Request path and endpoint

  1. Where does a request go after the developer presses Enter?Name every hop: workstation, proxy, gateway, provider endpoint, region. If the path is not documented, draw it before anything else.
  2. Is the endpoint a public one, a private one, or one run inside the boundary?This decides what may be sent at all, and which approvals apply.
  3. What can be sent in a request, and what must never be?Source files, file names, environment variables, command output, secrets in config files: list the categories, not just “code”.

2. Model and version pinning

  1. Which model identifier is used, and is it a fixed version or an alias that moves?An alias can change behaviour without any change in your repository. See the CI checklist for recording it with each output.
  2. Who decides when the model changes, and how is a change evaluated before it reaches shared work?A change in model is a change in tooling and needs the same review as any other.
  3. What happens when the pinned model is unavailable?Fail, fall back to another model, or wait. Each has a different audit consequence.

3. Prompt caching and cost

  1. Is prompt caching available on the endpoint in use, and what does it change about what is stored?Caching affects both cost and retention. Ask the provider or platform owner in writing.
  2. Is there a spending limit per user, per pipeline run, or per project, and who is told when it is reached?An unattended loop with no limit is a cost incident waiting for a trigger. Compare with the iteration limit in the CI checklist.
  3. How is usage attributed, and who reviews it?Per-user and per-job attribution is what makes an unexpected figure explainable.

4. Where logs live, who may read them

  1. Where are transcripts and logs stored, on workstations and in CI?Locally kept transcripts contain prompts, file contents and command output. Treat the directory like any other place that holds source.
  2. Who may read them, for how long are they kept, and how are they deleted?Retention and access rules for transcripts should be written the same way as for any other record that may contain source or data.
  3. Can a reviewer who was not present reconstruct what was asked, what context was supplied and what a person approved?If not, the log is not an audit record yet.

5. Feedback loop in the pipeline

  1. Does the assistant see real build and test output, or only its own description of what should happen?Real output is the feedback; a description is not.
  2. How many iterations may it run before a person is involved?Set a number and make the pipeline enforce it.
  3. Which results end a loop as failed, and where is that recorded?A loop that ends silently looks the same as one that succeeded.

6. Scope of context

  1. Which directories and files may the assistant read in a given task?Prefer an explicit list over “the repository”. Additional directories are an explicit decision, not a default.
  2. Which files must be unreadable to it?Credentials, local environment files, exported data, anything under a different classification.
  3. Is the scope the same on a workstation and in CI?A narrower scope in CI is normal; a wider one needs a reason.

7. Format of generated tests

  1. In which format and location do tests have to be, to be accepted by the existing pipeline?A test that the pipeline does not run does not exist. Use the framework and layout already in the repository.
  2. Who reviews a generated test, and against what?Against a specification that is independent of the code, not against the code under test.
  3. Are the tests allowed to be changed in the same change as the code they check?See freezing the test directory in the CI checklist.

8. Who maintains design documents

  1. Which documents describe intended behaviour, and who owns each one?If the assistant is told to read a document, someone is responsible for it being right.
  2. When code and document disagree, which one is corrected, and where is that recorded?Without a rule, each disagreement is settled differently each time.
  3. Is a document the assistant generated reviewed like any other change?A generated document that nobody owns drifts away from the code it describes.

9. Config directories and worktrees in the repository

  1. Which tool-created directories and files are committed, and which are ignored?See Configuration worth having. Decide it once and put it in .gitignore.
  2. May the tool create worktrees, branches or commits by itself, and where do they end up?Unreviewed branches and worktrees accumulate. See Tool behaviour to know in advance.
  3. Which shared settings may a developer override locally, and which are enforced centrally?Permission rules are the usual case; decide which ones are policy.

10. Working language and audit logs

  1. In which language are prompts, specifications and reviews written?Mixed-language records are harder to search and to audit. Pick one for the record, even if conversation uses another.
  2. Can an auditor who reads only that language follow a log end to end?Test it with a real log before the audit does.
  3. Are identifiers, commands and error messages kept verbatim in the record?Translating them makes a log impossible to match against the system that produced it.

Recording the answers

One short document per environment is enough. Copy this skeleton, fill in what is known, and write “unknown” where it is not.

Template (Markdown)
# AI assistant adoption: answers

Environment:
Date:
Owner of this document:

## 1 Request path and endpoint
Path:
Endpoint type (public / private / inside boundary):
Allowed in a request:
Never allowed in a request:

## 2 Model and version pinning
Model identifier (fixed / alias):
Change owner:
Behaviour when unavailable:

## 3 Prompt caching and cost
Caching available (yes / no / unknown):
Spending limit and who is notified:

## 4 Logs
Storage location (workstation / CI):
Readers, retention, deletion:

## 5 Feedback loop
Real build and test output supplied (yes / no):
Iteration limit:

## 6 Scope of context
Readable:
Not readable:

## 7 Generated tests
Format and location:
Reviewer and reference:

## 8 Design documents
Owners:
Rule when code and document disagree:

## 9 Config directories and worktrees
Committed:
Ignored:
Tool may create branches / commits / worktrees (yes / no):

## 10 Working language and audit
Language of the record:
Verified with a real log (yes / no):

Unofficial notes, not affiliated with or endorsed by Anthropic. Command names, flags and behaviour change between versions; the official documentation and the tool's own help output are authoritative.