> ## Content Index
> Fetch the complete content index at: https://piotrmechlinski.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Before You Build an AI Adviser, Build Its Context
- URL: https://piotrmechlinski.com/writing/build-ai-adviser-context/
- Published: 2025-10-10T22:00:00.000Z
- Updated: 2026-09-08T07:53:55.000Z
- Description: Build a portable context system that tells an AI adviser which decision, evidence, authority, judgment and boundaries matter.
- Author: Piotr Mechlinski
- Tags: Governance

Your AI adviser sounds generic because its context is generic.

A clever prompt cannot repair a missing business.

Leaders often begin with the interface. They choose a model, upload a few presentations and ask for strategy. The response is fluent. It knows the right frameworks. It can sound like a consultant who read the website on the way to the meeting.

The fluency hides the missing business context.

Strategic advice depends on choices the model cannot infer safely: which numbers are current, which constraints are real, what the board has already rejected, which customer promise matters and who owns the consequence.

Build that context before you build the adviser.

## Build a context system

Documents are only the raw material.

A useful context system tells the adviser what job it is doing, which evidence to trust, where uncertainty begins and how its work will be reviewed. It also keeps the source of truth outside the model interface, so the company can update or move it without rebuilding its institutional memory from scratch.

Start with six layers:

1. **Decision.** Define the exact question, decision owner, time horizon and output required. “Advise on growth” is too wide. “Challenge the assumptions behind entering Germany before the October investment decision” has a usable boundary.
2. **Evidence.** Provide the current strategy, financial view, customer evidence, operating data, risk constraints and relevant decisions. Record the owner and date for each source.
3. **Authority.** Rank conflicting sources. State which document governs, which is background and which contains an untested assumption. A board-approved constraint should not lose to an older sales deck because the deck uses stronger language.
4. **Judgment.** Encode the trade-offs leaders have chosen. Name the principles, red lines, risk appetite and conditions that would change the decision. This is where proprietary thinking becomes useful context.
5. **Boundaries.** Define what data may enter the system, who can access it, what must be excluded and when the adviser must stop and ask a human. Include retention, sharing and escalation rules.
6. **Learning.** Keep a record of questions, outputs, corrections and final decisions. Update the source material when reality changes. Test whether the adviser cites the right evidence, exposes missing context and remains useful across several real cases.

The file format matters less than discipline. Plain text and Markdown are useful because people can inspect, edit and move them. The source system may also include governed document stores, databases and approved retrieval tools.

Portability comes from keeping the authoritative material separate from the vendor-specific configuration.

## Use precise language

Uploading a document to a chatbot does not automatically mean the underlying foundation model has been trained on your company.

In many products, the document is supplied as context for a conversation or retrieved when the system answers. Fine-tuning is a different process. Product behavior varies, so describe what has actually been configured: grounded in approved sources, connected to a governed repository or fine-tuned under a documented process.

The distinction matters. “Trained on our strategy” can create false confidence about what the adviser knows, remembers and will use next time.

## Verify the exact product and plan

Privacy controls also vary by product, plan and feature.

[OpenAI's current business-data statement](https://openai.com/business-data/?ref=piotrmechlinski.com) says organization data in its listed business products is not used for model training by default. [Microsoft's Copilot Chat documentation](https://learn.microsoft.com/en-us/copilot/privacy-and-protections?ref=piotrmechlinski.com) says prompts and responses under enterprise data protection are not used to train foundation models, while interactions are logged for audit and discovery. [Google's Workspace guidance](https://support.google.com/docs/answer/14615114?ref=piotrmechlinski.com) says Workspace content is not used to train models outside Workspace without permission and warns that personal-account choices may follow different terms.

Each statement applies only to the named product, plan and feature.

Before strategic material enters any system, verify the exact contract, account type, retention, model-improvement setting, connected tools, administrator access, regional requirements and deletion or export path. Your security, privacy, legal and procurement teams decide what the company permits.

Check the connected sources as carefully as the chat itself. A governed model can still retrieve a document the user should not see if repository permissions, service accounts or connector scopes are wrong. Context quality includes access control.

## Test the adviser on a real choice

Return to the Germany question.

Without context, the adviser can produce a polished market-entry template. With the six layers, it should do something more valuable. It should identify which revenue assumption comes from the approved plan, flag that customer evidence is older than the pricing decision, recognize the board's capital boundary and ask who owns the missing regulatory view.

It may still be wrong.

Test whether the system used the right evidence, separated fact from assumption, respected the decision boundary and showed where human judgment must enter.

Pick one material question. Build the minimum context required to challenge it well. Keep that context portable. Then test the adviser against the decision you actually face.

Keep the context outside the model, where your company can govern and reuse it when tools change.

Your move.