Practice 04 / AI strategy
AI that survives contact with your business.
Choosing the tool is the easy decision, and it is the one most projects spend their time on. What actually decides whether a pilot becomes a habit is which data the thing may see, who is accountable for what it produces, and whether the task was worth automating before anyone automated it.
How we scope a pilot
The hard part of AI is never the model.
Four steps, in this order, because each one kills candidates that would otherwise waste a quarter. Roughly half of a typical shortlist does not survive the first step, and that is the cheapest failure available to you.
Talk through a use caseScreen the use case
Volume, tolerance for error, and who reviews the output before it counts for anything. If a human has to check every result anyway, the saving was imaginary.
Trace the data
What leaves your tenant, whose terms govern it once it has, whether it trains anything, and how long it is retained after you stop paying the bill.
Write the policy
One page your staff will actually read, and controls your insurer and your clients will accept when they ask what your AI position is.
Pilot against a number
One team, one quarter, one measure agreed in advance, so the decision to continue or stop is made by evidence rather than by whoever is most enthusiastic.
Where it earns its keep
The cases that tend to survive screening.
High volume, tolerant of a first draft, and already reviewed by a person before it goes anywhere. Those three properties predict success better than any product comparison.
Document drafting and review
First drafts of proposals, summaries and responses where a person was always going to edit the output before it left the building. The review step already exists, so nothing new has to be invented.
Inbox and request triage
Classifying, routing and summarizing the volume that arrives at a shared mailbox, with the low-confidence cases pushed to a human instead of guessed at.
Knowledge retrieval
Answering "where is the document that says" across systems that do not share a search index, and usually the highest-value and lowest-risk place to start.
Structured data extraction
Pulling fields out of invoices, statements and forms into something your systems can consume, with a confidence threshold below which a person still looks.
Meeting and call capture
Notes and action items, which is the most commonly deployed case and the one where the data-handling question is most often skipped entirely.
Workflow automation
The unglamorous part, and often the larger saving: the handoffs between systems that a person currently performs by copying from one window into another.
What you get
A decision you can defend, either way.
Including, frequently, a recommendation not to proceed yet, which is a legitimate outcome and considerably cheaper than the alternative.
The screened shortlist
Your candidate use cases ranked by expected return against effort and risk, with the reasoning for every rejection written down so the same idea does not return in six months unexamined.
The data-path map
For each surviving candidate: what data the tool sees, where it goes, under whose terms, for how long, and which regulatory or contractual obligations that engages.
The policy and the pilot
A one-page acceptable-use policy your staff will read, and a pilot defined with a single agreed measure and a date on which somebody decides.
Who you are working with
Copilot and Azure OpenAI, introduced across a bank.
Christopher Moskowitz brought Microsoft 365 Copilot, Azure OpenAI and the Power Platform into a 16,000-endpoint financial institution, with the governance and data-handling work that had to come first. He now runs a multi-node lab with GPU-accelerated local inference and agentic systems alongside the commercial models. The advice comes from operating both, and from being loyal to neither.
Common questions
Our staff are already pasting company data into chatbots. What now?
That is the usual starting position, and banning it outright tends to move the behaviour somewhere you cannot see. The first move is a sanctioned tool with terms you have actually read, followed by a one-page policy that says what may go into it. Enforcement comes third, not first.
Do you build the AI systems, or only advise?
Both, within reason. We scope and run pilots, configure the assistants and integrations that sit on platforms you already license, and build custom tooling where it is warranted. What we will not do is recommend a build when a setting in a product you own would do it.
Is this only about Microsoft Copilot?
No, though it is where most of these conversations start, because the licence is already in the tenant. We assess whatever fits the use case, including the answer that nothing currently does.
How do you decide whether a use case is worth it?
Volume, tolerance for error, and who checks the output. A task done twice a month, where a wrong answer is expensive and a human has to verify everything anyway, is a bad candidate no matter how impressive the demonstration was.
What does the AI policy actually cover?
One page: which tools are approved, what categories of information may and may not be entered, who reviews output before it leaves the organization, and what to do when someone gets it wrong. It is written to be read by staff, not filed by counsel.
Your staff are already using AI. The question is on whose terms.
info@vandien.io · (551) 236-3191 · Ridgewood, NJ, serving the New York metro