Start by mapping the work, not the tool
A good AI strategy starts with an understanding of what the organization does today. List processes that repeat, that involve reading or writing text, or where people search for information across several systems. For each process, note who does it, how often and where it gets stuck.
Alongside the processes, map the data: where it lives, who owns it, how sensitive it is and who is allowed to access it. This map does not need to be perfect. Its purpose is to enable a conversation about real options instead of general ideas.
Pick one or two use cases by value, feasibility and risk
From that list, choose one or two use cases to start with. Rate each candidate on three axes: how much value it can create for the work, how feasible it is with the existing data and team, and what a mistake would cost. A use case with moderate value and low risk is often a better starting point than an ambitious project.
The rating is not a precise formula. It is a tool for discussion that makes clear why one thing is chosen and another is deferred. Record the reasoning so you can return to it after the first experiment teaches you something new.
- Value: which work will get shorter, better or more consistent?
- Feasibility: is the data available, clean enough and accessible with the right permissions?
- Risk: what happens when the output is wrong, and who will notice?
Data and permissions readiness
An AI system connected to organizational data inherits all of that data's problems: duplicate documents, outdated information and permissions that were set up in a hurry. Before connecting it, verify that the system shows users only information they are allowed to see, and that the source and last-updated date of each answer can be identified.
Decide in advance which data must not be sent to an external service, and review the vendor's terms of use and data retention. These decisions are best made together with the people responsible for information security and privacy in your organization, not after the experiment is already running.
- Who owns each data source, and who approves connecting it?
- Do permissions in the new system reflect permissions at the source?
- Which data stays inside the organization, and which may be processed by a vendor?
Evaluation, human oversight and governance
Before expanding usage, build a set of real examples that includes edge cases, and define how you will check that the output is reasonable. Decide where a person must approve before an action is taken, and how users report a wrong answer. This check should be repeated after every change to the model, the instructions or the sources.
Governance does not need to start with a long policy. Frameworks such as the NIST AI RMF offer a shared language for identifying, measuring and managing risk, and you can use them as a list of questions rather than a form to fill in. The OWASP list of risks for LLM applications is also useful for checking known weak points.
A 30, 60 and 90-day plan
A first roadmap should be short and end with a decision. Three months is a reasonable frame for seriously testing one use case, but the actual timeline depends on your data, your team and your approval processes.
At the end of the period, decide on one of three steps: expand, change direction or stop. Each of these outcomes is useful learning, as long as it rests on what was measured rather than on an impression from a demo.
- 30 days: mapping, choosing a use case, defining success measures and checking data and permissions.
- 60 days: a limited experiment with real users, an evaluation set and a log of mistakes.
- 90 days: summarize results, decide whether to continue, and if so, plan operations and ownership.