- What was asked for
- “Predict which assets will fail”
- What it usually is
- A supervised learning problem — if failures were ever labelled
- The right response
- 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.
The enterprise AI practice
Enterprise AI in Saudi Arabia
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
AI that an operations team is willing to depend on
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.
Read more
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.
Relatedindustrial safety monitoring
Diagnosis
What the problem usually turns out to be
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
- “Automate this decision”
- What it usually is
- A rules engine, in the majority of cases
- The right response
- 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.
- What was asked for
- “Read these documents for us”
- What it usually is
- Document extraction, with a language layer over it
- The right response
- 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.
- What was asked for
- “A chatbot over our knowledge base”
- What it usually is
- A retrieval problem wearing a conversational costume
- The right response
- 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.
- What was asked for
- “Find anomalies in our data”
- What it usually is
- Usually thresholding; occasionally a real anomaly-detection problem
- The right response
- 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.
- What was asked for
- “We need an AI strategy”
- What it usually is
- Sometimes a strategy; often a shortlist of candidate use cases
- The right response
- 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
The model is the small part
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.
Read more
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.
Relatedobservability practice
Scope
How the work is usually shaped
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.
01
Feasibility and data audit
Does the data to solve this actually exist, at the quality and history depth the method needs? The most valuable output of this stage is a documented no, delivered before a budget is committed.
02
Modelling and evaluation
Building candidate models and, more importantly, defining what good means in the business’s own terms — including which kind of error is the expensive one, since precision and recall rarely matter equally.
03
Production engineering
Inference where the workload lives, integration with the systems that consume the output, and the fallback path for when the model is unavailable or unsure. Software engineering, done to the same standard as any other service.
04
Operation and retraining
Watching accuracy rather than only uptime, defining the trigger that says the model needs retraining, and running that cycle. This is the phase most programmes underfund and the one that decides whether year two looks like year one.
Governance
The questions a regulated buyer will be asked
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.
Read more
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.
Relatedtelemetry residency guide
The Saudi layer
What is specific to this market
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.
Read more
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.
When this is the wrong fit: a problem a rule can solve. If the decision can be written down as a policy someone would be willing to sign, a model adds a training set to maintain, a monitoring burden to carry and a category of failure that is hard to explain to an auditor — and it will not be more accurate. The same applies where nobody owns the outcome the model is supposed to change, which is the more common of the two.
Procurement
What to require from any AI supplier, including this one
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:
- The evaluation protocol in writing: which held-out data, which metric, which baseline, and the result that would mean stopping
- Which kind of error is treated as the expensive one, stated in your business’s terms rather than as a symmetric accuracy figure
- Where inference runs and whether any input leaves the Kingdom — answered per data class, not once for the whole system
- What the system does when it is unavailable or unsure, and which human process takes over
- Who owns the trained model, the training data and the derived artefacts at the end of the engagement
- How model performance will be monitored after go-live, what triggers retraining, and who is accountable for running that cycle
- Every third-party model, dataset or library with its own licence terms, named during scoping rather than at handover
Questions
Questions buyers actually ask
Common question
Do you need our data before you can say whether this is feasible?
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 clear 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
Can you use a hosted model instead of building one?
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
What accuracy can you commit to?
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
Is a proof of concept worth doing?
Yes, when it is scoped to answer a question that could change the decision. The useful shape has a stated threshold, a held-out evaluation set and an agreed stopping rule; without those, a proof of concept confirms what everyone already hoped and the decision is no better informed. It is the same discipline as the safety-monitoring pilot design applied to a different domain.
Common question
Who owns the model and the data at the end?
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
Where this leads
Product
SquintPRO computer vision
Interkey’s own vision product: what an applied model looks like once it has been through everything on this page.
MethodHow to scope a pilot that can fail cleanly
The stopping-rule discipline this page argues for, written out in full for a safety-monitoring deployment.
PracticeCustom software development
The engineering half. A model in production is a service, and it is built by the same people to the same standard.
PracticeSystems integration
A model in production is only as useful as the interfaces that feed it and consume it.
Explore related solutions
Next step
Bring the problem, not the technology
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 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia