AI for Business — What Works for Your Company and What Does Not

Four cases prove themselves in most companies: answering repeated customer questions from your own documents, reading invoices and contracts and extracting their data into your system, classifying and summarising incoming messages and complaints and routing them to the right department, and drafting marketing content for human review. What they share: repetitive text work that consumes hours and needs no final decision from the model.

Ask one question: can the rule be written down? If you can state "if this, then that" precisely, ordinary programming is cheaper, faster, more accurate, and does not err. AI earns its cost only when the inputs are irregular: free text, varied images, documents in different layouts. Many projects requested under the banner of AI are solved by a simple condition in code at a tenth of the budget.

Pricing is based on the volume of text processed rather than the number of users, which is why it varies so widely. An assistant answering a hundred questions a day from medium-length documents typically costs SAR 100 to 600 a month. A system reading a thousand invoices a month costs less than most people expect. Two factors cut the bill decisively: choosing a smaller model for simple tasks, and caching answers to repeated questions instead of re-asking the model each time.

All three handle most business tasks, and the differences are practical rather than fundamental: they differ in pricing, in how much document they take in one pass, in data retention policies, and in how well they handle Arabic. The right decision is not picking "the best" but building your system so the model can be swapped without rewriting everything — because the ranking between them shifts with every new release, and releases are constant.

Use a ready API — that is the right answer for well over ninety percent of companies. Training your own model requires thousands of hand-labelled examples, hardware, expertise, and periodic retraining, and usually produces a weaker result than a ready model supplied with your documents. If your goal is for the model to know your company’s data, the answer is not training but RAG — orders of magnitude cheaper and far easier to keep current.

RAG first searches your documents for the passages related to the question, then hands those passages to the model to answer from them specifically. Its importance is threefold: the answer rests on your documents rather than general knowledge, the source it came from can be shown so verification is possible, and updating a fact means updating a file with no retraining. This is the standard technique for building an assistant that knows your company’s policies, prices, and procedures.

Four steps: gather the knowledge sources — FAQs, product manuals, return policies, price lists; clean them of contradictions, because the assistant will faithfully repeat your contradictions; build a search index over them; then connect it to an interface on your site, on WhatsApp, or inside your system. The second step is the longest and most important — most assistant projects fail on contradictory sources, not on the model.

Business accounts with the major providers typically state that your data is not used to train their models, unlike free personal accounts whose terms may differ. Even so, the practical rules hold: do not send national ID or card numbers unless the task requires them, mask what can be masked before sending, and read the data retention policy rather than the marketing summary. And for the most sensitive data, models exist that run entirely on your own infrastructure.

This is not a fault fixed once but a property of how models work, managed by design. Three effective measures: require the model to answer only from specified documents and to show its source, make it say "I do not know" explicitly instead of guessing when no source is found, and keep human review on any output with financial, legal, or medical consequence. A well-designed system admits ignorance — that is a quality signal, not a weakness.

Start with recurring questions only — opening hours, order status, return policy, prices — and leave everything else to a human. Make the handover to a person clearly available from the first message rather than hidden behind five attempts. And review the escalated conversations weekly to fold them into the knowledge base. That weekly review is what raises the automatic resolution rate over time; without it the system stays at its day-one level.

Modern models handle Modern Standard Arabic with high competence, and Gulf dialects well in comprehension though slightly weaker in natural generation. The most common errors fall on sector-specific local terminology, and on names and addresses. The practical fix: supply the system with your own glossary and product names in their local forms, and test it on fifty real customer messages before launch rather than on invented examples.

Use it for three tasks it does well: summarising large volumes of text such as customer feedback and extracting the recurring patterns, turning a question written in plain language into a query against your database, and explaining why a given number moved by looking at related data. Do not use it to compute the numbers themselves — computation is the database’s job, and a model can get it wrong with complete confidence.

Use it to accelerate drafts rather than replace judgement: generating ten phrasings of one headline to choose between, reworking a long piece for different platforms, a first-pass translation reviewed by a human, and mining content ideas from your customers’ real questions. What to avoid: publishing text no human has read. Unreviewed published content erodes reader trust and your search standing at the same time.

Yes, and it is among its most successful practical applications because the return is directly measurable. A model can read an invoice in a layout it has never seen and extract the number, date, amount, vendor name, and tax lines. The condition that makes it safe for accounting: any field with low confidence goes to human review, and totals are checked arithmetically before posting. Without those two guards, speed turns into silent errors.

A chatbot answers. An agent acts: it reads the request, decides the steps required, and uses real tools — searching a database, creating a record, sending a message, booking a slot — then verifies the outcome. The practical difference is that an agent needs permissions on your systems, which is why its permissions must be as narrow as possible, its actions logged, and its financially consequential steps gated behind human approval.

Through four elements together: allow the AI crawlers access in robots instead of blocking them; publish pages that each answer one specific question with a short direct answer, because models quote a self-contained paragraph rather than a long page; apply FAQPage schema so your question-and-answer structure is understood; and add an llms.txt file stating your identity and what should be attributed to you. This site itself is built on those four rules.

SEO targets your rank in a list of links. GEO targets being quoted inside the generated answer at the top of the page. AIO is broader — being named when someone asks a language model directly with no search engine involved. Why SEO alone is no longer enough is simple: a growing share of questions end in an answer the user reads without clicking any link. Whoever is not named in that answer disappears, even ranked first.

Directly: write a list of twenty to thirty questions your real customer would ask, put them to ChatGPT, Gemini, and Perplexity monthly, and log in a sheet whether your name appeared, in what position, and alongside which competitor. This check can be automated to run on its own and send you a report. What matters more than the number is its trend across months, because answers naturally vary between one session and the next.

Four realistic risks: publishing something false in your name because nobody reviewed the output; leaking customer data by sending it to a service whose terms were never read; a run cost that grows without ceiling because nobody set a usage cap; and full dependence on one provider, so your operations stop if its pricing or terms change. All four are managed with simple measures, but ignoring them is what turns a promising project into a loss.

Yes. The Saudi Data and Artificial Intelligence Authority (SDAIA) is the reference body, and it has issued AI ethics principles alongside the Personal Data Protection Law governing how data is collected, processed, and transferred outside the Kingdom. Practically this means three obligations on any project: a clear lawful basis for collecting data, transparency with users that they are dealing with an automated system, and care in transferring personal data abroad. Consult the authority or a legal adviser before launching any system handling personal data.

Choose one narrow, measurable use case and build a pilot in two weeks that runs on real data in front of real users. That pilot typically costs a small fraction of a full project and answers the most important question before you commit a large budget: does the result actually improve the work? The most expensive mistake in AI projects is building a comprehensive platform before proving the value of a single case.

A pilot takes one to three weeks. A production-ready version takes six to twelve weeks, and the difference is not the model but everything around it: handling anomalies, capping cost, logging operations, the human review path, and testing against varied real data. Anyone promising a production solution in a week is describing a pilot, and the difference between them shows up in the first month of operation.

For projects using ready models through their APIs — which is most small and mid-sized company work — an experienced developer who understands working with data is enough. You need a dedicated data engineer when handling millions of records, building a data warehouse, or running daily pipelines over large volumes. Start with the former and add the latter only when data volume itself becomes the bottleneck.

Do not start with a general workshop about "AI". Start with one task the employee performs weekly, show them how it is done with the tool in half the time, then let them try it themselves in front of you. After three such tasks the team starts discovering uses you never considered. Document what works on a shared internal page, and set one explicit rule: anything going out in the company’s name is read by a human first.

Send a description on WhatsApp at wa.me/966573784181 of one repetitive task in your company that consumes time and depends on reading text or documents. You get a free first read answering three questions: is AI even the right tool for this case, or would ordinary programming be cheaper? What is the approximate build cost and monthly run cost? And what is the smallest version that could be launched to test feasibility before committing?