The Five Commandments of AI Implementation
I have audited over forty AI deployments across retail, finance, and logistics. Not all of them were mine. Some I was brought in to fix after they had already collapsed. After enough of these, a pattern hardens into something you cannot unsee.
The organisations that succeed share five practices. Not philosophies. Not "AI strategies" in a slide deck. Actual, operational, non-negotiable things they do. The ones that skip any of these — regardless of budget, regardless of how good their data science team is — build systems that degrade within six months.
I. Never Deploy Without an Audit Trail
Every decision the AI makes gets logged. Not logged in a way that someone might check later. Logged in a way that someone can verify later — with cryptographic certainty. SHA-256 hash chaining. Immutable. Auditor-ready.
I have seen what happens without this. A retail chain deployed an AI pricing engine that started discounting high-margin items at 3 AM — nobody noticed for six weeks. When they finally caught it, they could not trace which version of the model made which decision, or when the behaviour changed. They lost R480,000 before anyone could prove what happened. An audit trail would have caught it in 48 hours.
The audit trail is not a compliance checkbox. It is the only thing that lets you debug a system that operates while you sleep.
II. Ground Every Automation in a Human Gate
Not every action needs human approval. But every category of action needs a human gate that can be tightened or loosened based on risk. Email drafts? Human reviews, human sends — always. Appointment booking? AI can book, human confirms. Content generation? AI drafts, human edits.
The gate is not a bottleneck. It is a dial. When the system is new, the gate is tight. As trust builds, you loosen it — but you never remove it entirely.
III. Build for Verification, Not Just Execution
Most teams build AI systems to do things. The ones that last build them to be verified. Every output should be checkable. Every decision should be explainable. Every workflow should have a "what just happened and why" view that a non-technical operator can read.
I build dashboards not because they look good in demos. I build them because when something goes wrong at 11 PM, the person on call needs to know what happened without opening a log file.
IV. Measure What Actually Changes
Before-and-after metrics. Not model accuracy. Not "engagement rates." Real operational metrics: time-to-response, booking completion rate, revenue per interaction, human hours saved. If you cannot measure the delta, you cannot justify the system.
The hospital AI concierge I built replaced $12,000/month in human staffing with a system that costs $895/month to run. That is not a model metric. That is a P&L line item.
V. Own the Stack
Do not outsource the integration layer. The model you can swap. The orchestration — how intents are routed, how agents communicate, how state is managed — that is your intellectual property. If a vendor owns your orchestration, they own your business logic. Every successful deployment I have seen keeps the orchestration in-house, even when the models come from elsewhere.
These are not optional. They are not "nice to have." They are the difference between a system that runs for years and one that you are embarrassed to mention six months after launch.