Ask what information the task actually needs.
The easiest sensitive data to protect is data a workflow never collects. Define the purpose of each field, where it will be processed and who needs access. Keep unnecessary personal information out of prompts, support logs and analytics. Treat credentials and financial account details as separate, tightly controlled information.
Make permissions specific.
An assistant should not inherit broad administrator access simply because it can use an API. Give it a narrow identity, limited tools and a clear operating boundary. Evaluate access when the action occurs. Instructions found inside a document or incoming email should not be allowed to change those permissions.
Design the review, not just the output.
A person reviewing an AI suggestion needs the source, the proposed change and the consequence of approving it. Showing a polished paragraph alone is not enough. Present relevant evidence, identify uncertainty and keep approval separate from the action that follows it.
Consider the entire information lifecycle.
Information can persist in source records, attachments, search indexes, logs and backups. Plan retention, export and deletion across the full path. Decide how access changes propagate and what happens if a customer ends the service. These choices are easier to make before the workflow accumulates years of records.
Match assurance to the actual deployment.
A public architecture statement cannot establish that a particular implementation satisfies every regulatory or contractual requirement. The customer, geography, data and use case determine which obligations need assessment. Define the controls, evidence, owners and review process for that scope, and keep external claims aligned with what has actually been verified.
Choose one workflow. Establish the baseline. Define the boundaries. Build on a result you can understand.