The enterprise AI practice
Most enterprise AI programmes do not fail at the model. They fail at everything the model needs in order to be trusted: data nobody has cleaned, a decision nobody will own, and an accuracy figure nobody can reproduce six months later. This practice is built around that gap.
In short
Interkey builds and delivers machine-learning systems for organisations in Saudi Arabia: data science, model development, and the engineering that puts a model somewhere it runs every day rather than in a notebook someone reopens for the quarterly review. The work spans strategy, modelling and delivery, using the mainstream open frameworks and GPU stack, and it is done from Riyadh.
The distinction this practice cares about is not which framework. It is whether the output is something a team will act on without checking it by hand every time. That is a question about data lineage, failure behaviour, review workflow and who signs off — and it is answered, or not, long before anyone trains anything.
There is a worked example of the destination on this site. SquintPRO is Interkey’s own computer-vision product, and industrial safety monitoring is the domain it is applied in. If your problem is cameras watching a site, start there instead of here: this page is about the practice, that one is about the product.
Diagnosis
Half of what arrives described as an AI project is something else with a better budget line. Naming it correctly is not pedantry; it decides whether you are buying a model, a report, or a fortnight of SQL.
| What was asked for | What it usually is | The honest response |
|---|---|---|
| “Predict which assets will fail” | A supervised learning problem — if failures were ever labelled | Genuine, and one of the strongest cases in industry. It stands or falls on maintenance records: no labelled failure history, no model. Establish that first, because building the history is itself a project. |
| “Automate this decision” | A rules engine, in the majority of cases | If a domain expert can write the rules down, write the rules down. A deterministic system is cheaper, auditable, and does not drift. Recommending it costs us the model and keeps the client. |
| “Read these documents for us” | Document extraction, with a language layer over it | Real and well-suited, with one condition attached: define what an unacceptable error looks like before scoping. Extraction that is right most of the time is either transformative or useless depending entirely on what the wrong answers cost. |
| “A chatbot over our knowledge base” | A retrieval problem wearing a conversational costume | The hard part is the corpus, not the interface: unversioned, contradictory or stale source documents produce a confident assistant that is wrong in a new way each week. Fix the corpus or do not ship the assistant. |
| “Find anomalies in our data” | Usually thresholding; occasionally a real anomaly-detection problem | Ask what happens when it fires. If nobody has agreed who investigates and what they do, the model will be switched off within a month of go-live, and that outcome is worth predicting for free. |
| “We need an AI strategy” | Sometimes a strategy; often a shortlist of candidate use cases | A defensible answer here is a ranked list with the data dependency named against each entry. A strategy document with no data audit underneath it is a slide deck. |
Where the work goes
Where an AI budget actually goes
The proportions surprise people who have only seen the demo stage. Assembling, cleaning and labelling data, then understanding what its gaps mean, is the bulk of most engagements. Model selection and training is comparatively short, and often ends with a simpler architecture than the one the project started expecting — because a model an engineer can reason about when it misbehaves is worth more in production than one that scored marginally better in evaluation.
Then there is the part that is nobody’s favourite and decides everything: deployment, monitoring, retraining and rollback. A model in production is a piece of infrastructure with a decay rate. Inputs shift, upstream systems change their formats without telling you, and a system that was accurate at go-live is not automatically accurate a year later. The engagements that hold up are the ones where someone owns that curve.
This is also where an AI practice and an observability practice stop being separate conversations. A production model needs the same treatment as any other service — instrumented, alerted on, and visible to the team who will be paged — plus one thing ordinary services do not need: a way to notice that the answers have quietly stopped being right while every system metric stayed green.
Scope
Four shapes, in the order they normally happen. Each can be the last one, and stopping after any of them is a legitimate outcome rather than a failed programme.
Governance
Answer these before deployment, not during review
Saudi organisations deploying AI into anything consequential are accountable for how the system behaves, and the accountability does not transfer to a model vendor. The questions that actually get asked are consistent, and none of them is about architecture:
What data was it trained on, and was that use permitted? Personal data used for training is still personal data, and the lawful basis for holding it is not automatically a lawful basis for training on it. This needs a documented answer, produced with the organisation’s own privacy function rather than around it.
Where does inference run, and where does the input go? A hosted model API means the input leaves the estate. For some classes of data that is fine and for others it is the end of the conversation — which is the same residency question the telemetry residency guide works through, arriving one layer up.
Can a decision be explained to the person it affected? If the output influences a person’s access to something, someone will eventually have to explain a specific case. Systems designed to log their inputs and their confidence can do this; systems that were not, cannot be retrofitted to do it afterwards.
Who can turn it off? A named human, a documented procedure, and a system that degrades to a defined behaviour rather than an outage. Programmes that cannot answer this have not finished, whatever the evaluation scores say.
The Saudi layer
Three things change the shape of an AI programme here rather than merely translating it.
Arabic is a first-class requirement, not a localisation task. Any system touching documents, tickets, transcripts or customer messages meets Arabic immediately, and general-purpose models handle it unevenly — dialect, transliterated names, and mixed Arabic-English text in the same field are all normal here and all sources of quiet error. This has to be tested on real local data during evaluation, not discovered in production.
Residency constrains the architecture before the use case does. Where inference may run, and whether inputs may leave the Kingdom, are answered by the data classification — and the answer decides between a hosted API and infrastructure you operate, which is a different cost base and a different team. Deciding it late is expensive; deciding it first is free.
The scarce resource is people who can operate it. Building a model is a project and can be bought as one. Running it for years is a capability, and a programme that quietly assumes a team it does not have is the most common way good models end up switched off. Being explicit about who operates the system after handover is part of the scope, and it is one reason this work is delivered from Riyadh rather than remotely.
Procurement
A supplier who cannot answer these is not necessarily the wrong supplier, but the answers change the price and the risk, and finding them out after signing is how programmes go wrong. Put them in the RFP:
Questions
Common question
To say anything reliable, yes — but not all of it and not immediately. A schema, a description of how the data is captured, and an honest account of its gaps is usually enough to tell whether a method is plausible. What cannot be done responsibly is a feasibility answer from a use case alone, because feasibility is almost entirely a property of the data rather than of the problem.
Common question
Often, and it is frequently the right answer for language tasks: building from scratch what an existing model already does well is expensive engineering theatre. The decision is made on data classification and cost at volume rather than on preference. Where inputs may not leave the estate, a hosted API is out regardless of how well it performs, and that constraint is worth establishing in the first conversation.
Common question
None, before seeing the data — and any figure quoted before that point is a sales number rather than an engineering one. Accuracy is a property of a specific dataset, a specific task definition and a specific measurement method. What can be committed to is the evaluation protocol: how performance will be measured, on what held-out data, against what baseline, and what result would mean the project should stop.
Common question
Only if it is scoped to answer a question that could change the decision. A proof of concept designed to succeed proves nothing and costs a quarter. One with a stated threshold, a held-out evaluation set and an agreed stopping rule is genuinely useful, and it is the same discipline as the safety-monitoring pilot design applied to a different domain.
Common question
The client, and it is worth having that in writing before work starts rather than discovering the position afterwards. Training data, derived artefacts and the deployed model are the client’s; the general methods are not exclusive to anyone. Any third-party component with its own licence terms is named during scoping, not at handover.
From the insights library
Interkey’s own vision product: what an applied model looks like once it has been through everything on this page.
MethodThe stopping-rule discipline this page argues for, written out in full for a safety-monitoring deployment.
PracticeThe engineering half. A model in production is a service, and it is built by the same people to the same standard.
PracticeA model in production is only as useful as the interfaces that feed it and consume it.
Explore related solutions
Next step
Describe the decision you want to improve and the data you already capture. The first useful answer is whether this is a modelling problem at all — and that answer is free.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia