Preparing for local AI is less about buying a server than understanding the work and how it is governed. A little context helps reveal constraints early without treating installation as a substitute for security planning.
You do not need every technical detail in advance. Bring what you know, note uncertainties and involve the people who own the relevant systems and information.
Describe one real workflow
Choose a task the team already performs. Explain who handles it, what starts it, which systems and records are involved, and what success looks like. Note exceptions too: missing documents, conflicting instructions, urgent requests and work requiring professional judgement.
Be specific about the role AI might play. Is it finding relevant passages, preparing a first draft, extracting a few fields or summarising a meeting? “Help with admin” is understandable, but it is not yet a design requirement. A narrow description gives everyone something testable.
Make an information inventory
Identify the source material and where it lives: document management, shared folders, business applications, email or scanned paper records. Consider whether it is current, whether duplicates exist and who is entitled to see it.
Some material may be unsuitable for a first test. Record any sensitivity, retention or confidentiality considerations and ask the right internal owner before using it. Data minimisation still matters when processing is local: a workflow should only be given the information it needs.
Bring the network picture
If available, gather a high-level view of the network, storage, user accounts and backups. Note cloud-hosted applications, remote access, managed IT support and existing security controls. Do not share passwords or confidential network diagrams in an introductory discussion.
Ask who would approve equipment on the network, manage accounts, apply updates and respond if something stops working. An on-premises system still needs maintenance, monitoring, backup and recovery planning. Decide how responsibility will be shared between the firm, its IT provider and the AI supplier.
Think through access and review
List the roles that might use the system and the difference between what each role should be able to see. Consider how existing identity and permission controls can be respected. Decide who reviews output, how errors are corrected and where final work is stored. If the AI produces drafts, make it clear that they are drafts.
Good preparation also means agreeing what the system must not do. Perhaps it must not send correspondence, make a client decision or read an entire archive. Capturing these limits now helps prevent a pilot from quietly expanding beyond its purpose.
Set expectations for the model
Local models vary in capability and resource needs. Model type, number of users, document length and expected speed affect hardware choices. Some frontier models are not practical to run locally. Describe the work first, then assess options rather than assuming every model will fit.
Plan a test using approved, representative examples. Include difficult cases and define how staff will judge quality, usefulness and failure. If a workflow touches regulated or otherwise sensitive material, involve the firm’s privacy, compliance, security and professional advisers as appropriate. On-premises deployment does not itself establish legal compliance or guaranteed security.
What can wait
You do not need a polished business case, a complete data catalogue or a final hardware specification to start learning. Begin with a genuine task, a high-level map and honest questions. A careful assessment can identify what else must be established before a pilot proceeds—and whether local AI is the right fit at all.