The 30-day pre-deployment checklist

Before the Box Arrives

The contract is signed. The hardware is ordered. The project kick-off is on the calendar. And someone — probably you, possibly someone on your team who has been volunteered — is now responsible for making sure everything is ready when the deployment starts.

This checklist has been refined across more than a dozen SME AI deployments. Not every item applies to every organization, and some items will be done in hours while others take days. The goal isn't completeness for its own sake — it's making sure the first weeks of deployment are spent on configuration and learning rather than on discovering that your file structure is incomprehensible or that nobody told the IT manager the hardware was arriving.

Week 1: Data Inventory (Days 1–7)

The single most common cause of delayed or underperforming AI deployments is arriving at the deployment with a poor understanding of your own data. Week one is about fixing that.

• Enumerate your document types. Every format that will flow through the system: PDFs, Word documents, spreadsheets, email archives, scanned records, database exports. List them. Count the approximate volume. Note which are machine-readable and which are scanned images requiring OCR.
• Identify your primary knowledge repositories. Where does your operational knowledge actually live? Shared drives, SharePoint, Notion, internal wikis, email threads, people's heads? All of it counts, and you need to know where to look before you start organizing.
• Do a quality audit on your highest-priority documents. Take a representative sample (50–100 documents) from each major category and assess: are they consistently formatted? Are they clearly titled? Do they contain what the title suggests?
• Identify outdated material. A knowledge base that includes superseded policies, old pricing documents, and deprecated process guides is actively harmful — the system will retrieve this material and treat it as current. Mark it for exclusion or archiving.
• Assign ownership. Every document category should have a named human being responsible for keeping it current after the deployment. This is not an IT function. It's a business function.

Week 2: Infrastructure Readiness (Days 8–14)

The good news is that on-premise AI hardware typically requires less infrastructure preparation than people expect. The bad news is that what it does require often hasn't been done yet.

• Verify physical space and power. Confirm rack space, power specifications, and any cooling requirements with your deployment team. Don't assume this is handled.
• Test your network configuration. The AI system needs to talk to your file servers and, in some configurations, to user endpoints. If your network has VLANs, firewall rules, or segmented zones, confirm that the necessary access paths are open before the hardware arrives.
• Confirm your SSO configuration. If the system will integrate with your identity provider (Active Directory, Azure AD, Okta), test the configuration before deployment. This always takes longer than expected.
• Check your backup infrastructure. The AI system and its knowledge base need to be included in your backup strategy. Where does this live? Who's responsible?
• Document your current file access permissions. If some staff should have access to some documents but not others, now is the time to decide that — not after the system is running.

Technology deployments fail for people reasons more often than technology reasons. Week three is about the humans.

Week 3: People and Process (Days 15–21)

• Identify your power users. Two or three people who will adopt the system early, use it actively, and become your internal champions. These people will set the tone for how the rest of the organization perceives the system.
• Map the tasks you're automating. For each task the system will handle, document: who currently does it, what they'll do differently once the system is running, and how quality will be monitored. "The AI will do it now" is not a process design.
• Prepare your knowledge base inputs. Take the structured knowledge from your data inventory and organize it into the format your deployment team specifies. This usually involves some combination of document cleanup, folder reorganization, and simple metadata tagging.
• Draft your use case documentation. For each intended use case, write one page: what the system should do, what a good output looks like, what should trigger escalation to a human. This is both a training document and a quality benchmark.
• Talk to your IT insurance broker. AI systems that process sensitive client data may need to be disclosed to your cyber insurer. An hour's conversation before deployment is cheaper than a coverage dispute after an incident.

Week 4: Adoption Readiness (Days 22–30)

• Communicate before launch, not after. Tell your team what's coming, why, and what it means for their day-to-day work. The message should be specific: "Starting Monday, you'll use [system] for [specific tasks]. Here's how it works. Here's who to ask if something doesn't look right."
• Set up your feedback mechanism. How do users report outputs that are wrong, irrelevant, or missing? This needs to be simple and low-friction — a dedicated Slack channel, a feedback button, a shared document. Whatever gets used.
• Define your review process for the first 30 days post-launch. Every deployment benefits from a heightened review period. Who reviews the system's outputs? How often? What triggers a pause-and-reassess?
• Schedule your first month review. Put a date in the calendar right now, 30 days post-launch. Don't wait for something to go wrong before reviewing.