“Add AI to our business” is not yet a project brief. It becomes one when you identify a specific task, the information required and the person responsible for the result. South African businesses can begin with a modest pilot without pretending that an assistant should control an entire operation. The first decision is what not to automate.
Map the current work before choosing a model
Describe what starts the task, what information staff collect, what decisions they make and where the output goes. Record exceptions: incomplete requests, conflicting records and urgent cases. If the process is unclear to a person, adding a language model may reproduce the uncertainty rather than remove it.
Compare the proposed AI workflow with a simpler form, rule or ordinary integration. A fixed calculation or exact routing rule does not necessarily need generative AI. Language interpretation, drafting and summarising may be appropriate candidates, provided the required accuracy and review process are explicit.
Start with preparation rather than unrestricted action
Possible pilots include drafting a response from approved service information, classifying a request for staff review or answering questions from a bounded document set. These are planning examples, not claims about completed MBICT client projects. Keep sending messages, approving financial transactions and making sensitive decisions outside the pilot unless there is a separately authorised, appropriate control design.
Define the knowledge and permission boundary
Identify the owner of every data source, the permitted use and the users who may see its content. Decide how outdated information is replaced and what happens when two sources disagree. A public assistant should not gain access to private customer records simply because those records exist elsewhere in the business.
NIST’s AI Risk Management Framework is voluntary guidance for incorporating trustworthiness into the design, use and evaluation of AI systems. It is a useful planning reference, not a certificate that makes an implementation safe or legally compliant. Your own data handling and approval requirements still need review.
Write acceptance cases before the demonstration
Test normal inputs alongside missing information, ambiguous requests and instructions that try to override the workflow. Check whether the system admits uncertainty and whether it refers unsupported requests to a person. For a document assistant, compare answers against the approved source rather than treating confident wording as evidence of correctness.
Define who reviews the results and what constitutes a release blocker. Keep a record of failed cases and retest them after changes. A good demonstration is not a substitute for acceptance testing with the real kinds of questions your staff or customers will ask.
Budget for running and maintaining the workflow
Model usage, API calls, storage, hosting and integration maintenance can continue after the build. Compare the original process with pilot results using the same task boundary; include review and correction time rather than counting only the automated step. Do not quote a savings percentage before measuring it.
Agree who can pause the system and how work continues if an upstream provider is unavailable. Explore MBICT’s AI and workflow automation service and indicative project allowances. If the problem is inconsistent business records, begin with data preparation and migration planning before commissioning an assistant.