شركة أمن البيانات

Request a consultation

Secure AI & Automation

Managed AI Platforms & LLMOps Keep AI platforms healthy, measured and within budget

We operate AI platforms after go-live, whether they were built by your team, by us or by another provider: monitoring, evaluation on every change, controlled updates with rollback, tested backup and recovery, and capacity and cost reporting. Scope, responsibilities and support hours are set in the contract.

Request a proposal for this serviceTalk to sales on WhatsApp

Or call sales directly: +966 59 750 4669Sales hours: Sunday–Thursday 9:00–17:00

At a glance

Frameworks

  • NCA ECC
  • ISO 22301
  • ISO/IEC 42001
  • NIST AI RMF

Deliverables

  • Service description with the responsibility matrix, support hours and escalation
  • Monitoring and evaluation dashboards
  • Change and rollback procedure, with the regression set and baseline scores
  • Recovery runbook and a report for each recovery drill
  • Monthly report on availability, quality, incidents, changes, capacity and cost

When you need this service

  • The pilot is live and no one owns it

    Users rely on an assistant or AI application, the project team has moved on, and patching, monitoring and updates have no owner.

  • Changes nobody measures

    Prompts are edited, models updated and documents re-indexed straight in production, and nobody checks what that does to the answers.

  • Costs rising with no explanation

    The model invoice or the demand for GPUs keeps growing, and you cannot tell which application drives it or what next year will need.

  • Auditors expect documented operations

    Your security team or auditors ask for change records, access reviews and restore tests for the AI platform, as they do for every other system.

The challenge

A pilot that works is the start of operations, not the end of the project. Once users rely on an AI platform, someone has to patch the model-serving layer and drivers, watch availability and latency, check answer quality after every change, update models and indexes without breaking them, back the platform up and prove it can be restored, and keep usage within budget. The project team has usually moved on, IT operations do not know the AI components, and nobody owns that work. Illustrative example: a model provider retires the version an internal assistant was built on, the replacement formats its answers differently, and the step that extracts fields from those answers starts failing without raising an alert.

In production, an AI platform is an information system like any other. The National Cybersecurity Authority (NCA) Essential Cybersecurity Controls (ECC-2:2024) are mandatory for the organisations in their scope, which NCA defines as government entities and organisations that own, operate or host critical national infrastructure, and they require change management, patching, backup and recovery, periodic access review, and event logging and monitoring as ongoing processes. At the same organisations, the Data Cybersecurity Controls (DCC) add requirements for the data the platform holds, and the Cloud Cybersecurity Controls (CCC) apply where it relies on cloud services. Financial institutions regulated by the Saudi Central Bank apply its Cyber Security Framework (SAMA CSF). Personal data in prompts, logs and backups remains subject to the Personal Data Protection Law (PDPL), including how long it is kept. ISO 22301, the international business continuity standard, gives a structure for recovery objectives and exercises.

What AI adds is that quality can drop with no outage at all: a model update, an edited prompt or a rebuilt index can change the answers while every dashboard stays green, so evaluation becomes part of operation. The NIST AI Risk Management Framework (AI RMF 1.0) and its Generative AI Profile treat monitoring after deployment as part of managing AI risk, and ISO/IEC 42001, the standard for AI management systems, covers the operation and monitoring of AI systems; both are international references, not Saudi requirements. NCA has also put its Draft AI Cybersecurity Guidelines (AICG-1:2026) out for public consultation in July–August 2026; we take them into account as direction, not obligation, because they are still a draft. Which requirements apply to you depends on who you are and what data you process, and mapping them belongs to AI Governance & Regulatory Readiness.

How we work

  1. 1

    Take over and set the baseline

    We review the platform as it runs today: architecture, models and their versions, prompts, indexes, configuration, access, backups, monitoring and cost. With your reviewers we build a regression set, fixed Arabic and English questions and tasks with reference answers that show whether quality has dropped after a change, and record the baseline scores. We then agree the responsibility matrix, support hours, escalation and change procedure, and list the gaps to close before we take responsibility.

  2. 2

    Operate and evaluate

    We monitor availability, latency, errors, usage and cost, apply patches and updates, run backups and access reviews, and handle incidents with your IT and security operations. Every change to a model, prompt, index or configuration is first evaluated against the regression set in a test environment, then approved by your named owner and released with a rollback plan.

  3. 3

    Report and improve

    A monthly report covers availability, evaluation scores, incidents, changes, capacity and cost against budget. Recovery drills run on the schedule set in the contract, and each one produces a report. In a periodic review we agree improvements, retire what is no longer used and add cases from incidents and user feedback to the regression set.

What is included

  • Platform and model operations

    Patching and updating the operating system, GPU drivers, containers, model-serving layer, AI gateway and vector database, renewing certificates and rotating keys and credentials, with a register of every model in use, its version and its licence.

  • Observability

    Dashboards and alerts for availability, latency and error rates, usage by application and team, GPU and storage use, and queue depth, with platform logs sent to your security information and event management platform (SIEM).

  • Evaluation on every change

    Regression sets built with your reviewers from your own Arabic and English tasks, scored against the baseline and the thresholds you approve, with results attached to each change record. A set only covers the cases it contains, so it reduces the risk of an unnoticed drop in quality; it does not remove it.

  • Controlled updates and rollback

    Changes pass through a test environment and a staged release, with approval from your named owner, model versions pinned where the provider allows it, and a written rollback step checked before release.

  • Secure CI/CD for AI components

    Prompts, policies, configuration and infrastructure definitions kept as versioned code and released through a continuous integration and delivery (CI/CD) pipeline, with dependency and secret scanning, integrity checks on model files, and separation between who makes a change and who approves it. These checks catch known problems; they do not prove a component is free of flaws. This is our DevSecOps practice, security built into development and operations, applied across our AI services rather than sold as a separate service.

  • Backup, recovery and drills

    Backups of configuration, prompts and model files, of indexes or the pipeline that rebuilds them, of regression sets, and of logs under your retention policy, with restore drills measured against recovery objectives your organisation sets and a report for each drill.

  • Capacity, performance and cost

    Usage and cost by application, team and use case, budget thresholds with alerts, capacity forecasts from usage trends, and recommendations to lower cost, each evaluated for its effect on quality before it is applied.

  • Access reviews

    Periodic review of administrator accounts, service accounts, API keys and roles, with access that is no longer needed removed. Our engineers use named accounts with multi-factor authentication and work through your privileged access management where you have it.

  • Incident handling with your IT and SOC

    Runbooks for AI-specific incidents, such as a drop in answer quality, suspected prompt injection, possible data exposure, a sudden rise in cost or a model provider outage, with security events passed to your security operations centre (SOC) and severity and escalation set in the contract.

How to work with us

Frameworks and regulations

We align the service with the frameworks your organisation is subject to.

  • NCA ECC
  • ISO 22301
  • ISO/IEC 42001
  • NIST AI RMF

Frequently asked questions

What is included, and which hours do you cover?

It depends on the scope you choose, and both are written into the contract. Platform operations cover monitoring, patching and updates, backup and recovery drills, access reviews, incident handling, capacity and cost reporting, and a regression check on every change before release. With evaluation and improvement added, we also extend the regression sets with your reviewers and propose and test changes that improve quality or lower cost. The contract sets support hours, priorities and escalation for each platform, and cover outside working hours is included only where the contract provides for it. Your business applications stay with the teams that own them: we run the AI platform they use, not the applications themselves.

Is this AIOps?

No. LLMOps means operating platforms built on large language models: the models, prompts, indexes, evaluation, capacity and cost. AIOps means using AI to run IT operations, for example to correlate alerts or spot anomalies in infrastructure monitoring, and it is not part of this service. Monitoring the availability and performance of your networks, servers and links belongs to our network operations centre (NOC) service, and day-to-day IT operations to Managed IT Services. The two meet at the infrastructure under the AI platform: if the NOC already watches those servers and links, the responsibility matrix records which alerts go to which team.

How are changes evaluated before release?

Against the regression set, in a test environment, before anything reaches users. Every change to a model, prompt, index or configuration runs on the same Arabic and English questions and tasks, built with your reviewers, and is scored against the baseline on the measures you agreed, such as grounded-answer rate, retrieval quality, refusals, output format, latency and cost per request. The results go into the change record, your named owner approves the release, and the rollback step is ready before it starts. Because a regression set only covers the cases it contains, we keep adding cases from incidents and user feedback. Larger changes, such as a new model or new tools for the system, may also call for independent testing under AI Security Assessment & Red Teaming.

What happens when a model or provider changes?

It goes through the same change procedure, so the replacement is evaluated before users see it. Commercial model providers retire some versions and update others; we follow their announcements, pin versions where the provider allows it, run the candidate replacement on the regression set, adjust prompts where needed and plan the release. If the embedding model changes, the document indexes must be rebuilt, which takes capacity and is scheduled as a change of its own. Open-weight models you run locally follow the same path for new versions, and your legal team reviews any licence change. If a provider changes its terms or where it processes data, we raise it with you and your data protection officer: sending personal data to a model running outside the Kingdom is a transfer question under the Regulation on Personal Data Transfer outside the Kingdom.

How are backup and recovery tested?

By restoring the platform in drills, not by checking that backup jobs completed. We restore into an isolated environment on the schedule set in the contract, run the regression set to check that the restored platform answers as it did before, and record the time taken against the recovery objectives your organisation sets. Rebuilding a large index from the source documents can be faster or more reliable than restoring it, and the drill shows which approach meets your objectives. Each drill produces a report of what worked, what failed and what is being fixed, which you can use as evidence for business continuity and audit.

How are cost and capacity reported and controlled?

Through monthly reports by application and use case, and thresholds that alert you before a budget is reached. We measure requests, tokens or compute, GPU use and storage from the platform and the gateway, and reconcile our estimates with provider invoices, which remain the reference for commercial models. Hard spending limits are enforced at the gateway where one is in place; designing that gateway belongs to Secure AI Gateway & Guardrails. Recommendations to lower cost, such as caching answers, a smaller model for simpler tasks or scaling down idle capacity, are evaluated on the regression set first, because a cheaper option can also lower quality. For platforms you run locally, capacity forecasts from usage trends show when more hardware will be needed and why. Your organisation sets the budget, and we report against it.

Who owns the platform, data and configurations, and what happens on exit?

You do, apart from third-party models and software, which stay under their own licences. Your data stays yours; configurations, documentation and deliverables are handed over as set in the contract. Where possible we keep configuration, prompts and policies as code in a repository you control, together with the regression sets, dashboard definitions and runbooks, so another team can take over. On exit, the exit plan agreed in the contract covers knowledge transfer to your team or another provider, and the accounts we used are removed or have their credentials changed. If your organisation is within ECC scope, ECC-2:2024 requires its contracts with third parties, managed services included, to provide for secure removal of its data at the end of the service, and we write that step into the exit plan.

How are incidents handled with our IT team and SOC?

Through a joint procedure agreed during takeover: we handle the AI platform, and your teams keep their roles. Platform faults are handled from the runbooks and escalated as the contract sets out; faults in the infrastructure underneath, such as networks, servers or storage, go to whoever runs it, whether your IT team, the NOC or Managed IT Services. Security events, such as suspected prompt injection, possible data exposure, unusual access or a leaked key, are sent to your SOC through your SIEM, and we carry out the containment steps on the platform that your SOC directs, such as revoking a key, rolling back a change or taking a feature offline. Where personal data may be affected, the decision to notify under PDPL rests with your organisation and its data protection officer; we provide the facts and the logs. This service does not replace your SOC.

  • IT Infrastructure & Managed Operations

    Managed IT Services

    IT operations and support by a managed team or resident engineers, with agreed service levels and regular reporting.

  • IT Infrastructure & Managed Operations

    Network Operations Center (NOC)

    Availability and performance monitoring of networks and systems, with early fault detection and escalation to reduce disruption.

  • Secure AI & Automation

    Private & Sovereign AI Platforms

    AI platforms on infrastructure you control: locally deployed models, isolation and integration, with every external dependency documented.

  • Secure AI & Automation

    Secure AI Gateway & Guardrails

    One governed path to approved models: identity-based access, prompt and output policies, sensitive-data redaction, audit logs, and usage and cost limits.

Sales

Talk to our sales team

Tell us what you need and we will prepare a proposal for this service, or reach sales directly by call or WhatsApp.

  • Unified number

    9200 33782

    For general enquiries about our services and for existing clients. Reachable from within Saudi Arabia.

  • Mobile (calls and WhatsApp)

    +966 59 750 4669

    The direct sales line, by call or WhatsApp: a quick quote or a question about this service, and for existing clients.

  • Address

    3173 Al Abbas Ibn Abdulmutalib, At Taawun, Riyadh 12475

    Open the map ↗
  • Looking for a job at DataSec? Open roles