How to Run an AI Documentation Assistant Inside an Enterprise Tenant

In a regulated company the question is rarely "which AI tool is best?". It is: can we use AI without source code, specifications or customer data leaving our tenant — and can we show audit how it works? This guide answers that question. It is based on a production deployment at a Tier-1 financial services firm, where an in-tenant AI documentation workflow cut documentation time by 60% and was signed off by engineering, product and audit without rework.

Start with the constraint, not the tool

Model quality is rarely the blocker. Data leaving the tenant is. So fix the design constraint before you look at a single tool: nothing proprietary leaves the perimeter, and every output can be traced back to its source.

Step 1: Get a business-approved blueprint

Before choosing a tool, write a one-page blueprint and take it through business approval. It should name three things:

• Sources of truth — for example the source code and the vendor's published API contract. Drifted legacy specifications are a cross-check only, never an input.
• The data constraint — no source code, specifications or drafts leave the tenant; no third-party retrieval calls.
• The review model — who checks the AI output before it is used, what they check, and how the controls map to EU AI Act requirements.

Approval before the build turns a tooling experiment into a delivery that audit can follow. Every later output traces back to a source the business already endorsed.

Step 2: Show the faster options you turned down

Document the cloud tools that would have been faster, and why you rejected them: they cross the tenant boundary. The in-tenant choice then becomes a conscious business decision rather than a limitation — and that makes the later sign-off much easier.

Step 3: Set up the tenant-boundary controls

• Content exclusion on sensitive repositories, so selected paths are never read
• In-tenant operation — the assistant reads changed code from the internal repository; no telemetry leaves the boundary
• Authoritative inputs only — source code first, the vendor API contract second; legacy specifications only to flag drift to their owners
• Provenance — every generated statement cites the code line or specification section behind it

Step 4: Make the output checkable

Free text is hard to audit. Use structured outputs with schema validation (for example JSON schema and Pydantic), so the pipeline rejects documentation that refers to code that does not exist. The AI drafts, the schema checks, a person approves.

Step 5: Keep a person in the loop

Human-in-the-loop review is the control that matters most. Decide up front who reviews which output, what they check, and how approval is recorded. Then describe the controls in your auditors' language: data residency, traceability, technical robustness and human oversight.

Results from the field

• 60% less documentation time per release
• Shorter cycle: the end-to-end documentation cycle went from 3–4 weeks to under 1 week, because the first review no longer triggered rework
• First-review sign-off by engineering, product and audit
• Traceable output — every line linked to source code or the vendor specification
• No data egress — nothing left the tenant boundary

Readiness checklist

• Business-approved blueprint with named sources of truth and explicit out-of-scope inputs
• Documented trade-off: the faster options you rejected, and why
• Content exclusion on sensitive repositories
• In-tenant operation confirmed — no telemetry or retrieval leaving the boundary
• Provenance: every output cites its source
• Structured-output validation that rejects ungrounded statements
• Named human reviewers and a recorded approval step

Conclusion

In a regulated company the compliant option is the one that actually ships. Get the blueprint approved, keep the data in the tenant, make every statement traceable and keep a person in the loop. That is how an AI pilot becomes a 60% improvement instead of a rejected proposal.