# AI Pilot Review: Security questionnaire drafting

Prepared 2026-09-08 · TheTechStack Workbench · rules 2026-09-08.1
Status: Planning inputs captured — evidence and owner review still required
Planning aid only. Answers are self-reported, not verified evidence or deployment approval.

## Objective and current workflow
Reduce drafting time while keeping every submitted claim supported by an approved source.

Current process: Account team receives questionnaire → solutions engineer drafts → security lead reviews → account team submits.
Systems: Approved answer library and document repository
Volume: Illustrative pilot: 10 questionnaires; establish current review time first.

## Proposed workflow and access boundary
Request → permission check → approved context → draft or proposed action → human review → approved use
Requested capability: Draft for human review
Produce drafts only. A named reviewer approves their use; the pilot must not submit or change business records automatically.
This is a proposed workflow, not a connected integration.

## Accountability and risk
Owner: Solutions engineering lead (example role)
Approval: Security lead approves claims; account owner approves submission.
Stated consequence: High
Require explicit sign-off for consequential outputs, traceable evidence, and an escalation path. Exposure alone does not establish that a workflow is regulated; the responsible team must identify applicable requirements.

## Data and integration decisions
Read approved answer library only; enforce the requesting user’s permissions. Source owner checks freshness before each pilot batch.
Validate source access, freshness, retention, and audit requirements in each named system. Do not assume that an available connector has the right permissions.

## Evaluation plan
Use a reviewed example set with stale answers, conflicting sources, missing evidence, and unauthorized documents. Require supported claims and reviewer sign-off; block submission on unsupported claims.
Capture expected outcomes and actual results for representative tasks and failure cases. Record the dataset version, reviewer, and unresolved failures before expansion.

## Stop and rollback
Workflow owner pauses generation after an access violation or unsupported external claim. Revoke connector access and return to the manual process.

## Cost and operating measures
Measure drafting and review minutes, accepted answers, subscription costs, and model usage. Set the budget cap before the pilot.
Track accepted task rate, review effort, incidents, and total cost per accepted task. Establish the manual baseline before claiming improvement.

## Open actions
- No blank planning inputs remain. Validate the plan and collect test evidence; this is not a release approval.

## Release gates (not completed by this form)
- [ ] Scope and accountable owner agreed.
- [ ] Permission boundaries tested, including denied access.
- [ ] Evaluation evidence reviewed against agreed criteria.
- [ ] Required reviewers sign off on pilot scope.
- [ ] Stop mechanism and manual fallback exercised.
- [ ] Pilot budget and operating review cadence agreed.
Expand only after the accountable owner reviews results and unresolved risks.

## Build, buy, or extend
Compare extending current systems, buying a tool, and building a narrow component against the same workflow and acceptance criteria. Record capability fit, integration effort, controls, portability, and total operating cost before choosing.

## Previous attempts
Synthetic example; no customer deployment or measured result is claimed.

## Assumptions and limitations
This brief uses your stated scope and fixed planning rules. It does not inspect sources, test controls, select a vendor, or establish compliance. Unanswered questions remain unknown. Suggested controls require review by the responsible teams.