At a glance
A European manufacturing company was exploring how artificial intelligence could support production planning, quality control, equipment maintenance, customer service and internal knowledge management.
Different teams had already started testing AI applications. Some were using publicly available generative AI tools, while others were working with technology suppliers on more advanced solutions. These included an internal AI assistant, automated document processing and predictive maintenance for production equipment.
The company recognised the potential value of these initiatives. AI could help employees find information more quickly, reduce repetitive work and identify operational problems earlier. However, the projects were progressing at different speeds and were not being assessed through one consistent risk process.
The security team had information about systems, vulnerabilities and controls. The data protection team maintained records of personal-data processing. Procurement managed contracts and supplier assessments. Business teams understood the intended AI use cases. However, these different sources of information were not consistently connected.
This made it difficult to answer practical questions:
- ?Which business processes would depend on the planned AI solutions?
- ?What information would be used to train, prompt or operate the models?
- ?Could confidential, personal or production data be exposed?
- ?Which applications and infrastructure components supported each AI use case?
- ?Which external providers could access the company’s information?
- ?What would happen if an AI-generated output was inaccurate or misleading?
- ?Which controls were already in place, and which safeguards were still missing?
- ?Who was responsible for approving and monitoring each AI use case?
We helped the client build a connected cyber model covering AI use cases, business processes, applications, data, infrastructure, suppliers, cyber risks, controls and responsible owners.
The model did not make approval decisions automatically. It gave security, data protection, IT and business teams a shared view of each proposed AI solution, helping them identify dependencies, discuss risks and agree on proportionate safeguards.
About the client
This case study presents a representative and anonymised client scenario. Selected operational details and results have been adapted to protect confidentiality.
The challenge
The company’s AI projects had not all started through the same route.
The IT department was testing an internal assistant. Operations was working with an equipment supplier on predictive maintenance. Customer service wanted to summarise incoming enquiries automatically. Human Resources was considering an AI-supported knowledge tool, while individual employees were already using public generative AI applications for everyday tasks.
Each initiative had a business sponsor, but there was no complete overview of how the projects were connected with the company’s systems, information and suppliers.
An AI use case might appear low risk when considered on its own. The wider picture could be different. A solution could process confidential engineering documents, depend on an external model provider, access customer information and deliver outputs used in operational decisions.
The company’s existing risk registers and asset records did not represent these relationships clearly.
The main problems were:
The company needed a practical way to understand each AI initiative as part of a wider business and technology environment.
What the client wanted to achieve
The project had six main goals:
Create one reliable inventory of planned, active and experimental AI use cases.
Connect each use case with its business purpose, systems, data, models and suppliers.
Assess cyber, data-protection and operational risks through one coordinated process.
Identify the controls required before an AI solution could be approved.
Assign clear business, technical and risk owners.
Introduce ongoing monitoring so that important changes triggered a new review.
What we did
We started with the business purpose of each AI initiative
We did not begin with the technology. We began by asking what each team wanted to achieve and how AI would influence the relevant business process.
We held workshops with representatives from information security, IT, data protection, legal, procurement, operations, engineering, Human Resources and customer service.
For each use case, we recorded:
- ✓the business problem the team wanted to address;
- ✓the intended users;
- ✓the decisions or activities the AI output would support;
- ✓the expected business value;
- ✓the consequences of an incorrect or unavailable output;
- ✓the business and technical owners;
- ✓the current stage of development;
- ✓the conditions that had to be met before wider use.
This helped distinguish a low-impact productivity tool from a solution that could influence production, employment or customer decisions.
We created a common structure for AI use cases
The client’s AI information was stored in project documents, emails, supplier proposals and local spreadsheets. We created a common structure without forcing every team to replace its existing working tools immediately.
Each AI use case included:
- ✓an agreed name and description;
- ✓its business purpose and expected outcome;
- ✓the relevant business process;
- ✓the application and infrastructure involved;
- ✓the model or external AI service used;
- ✓the information entered, generated or stored;
- ✓the internal and external users;
- ✓the supplier and relevant subcontractors;
- ✓the business, technical and risk owners;
- ✓the identified risks, controls and approval status.
The inventory became the starting point for assessment, approval and monitoring.
We connected AI use cases with data and technology
We then mapped the systems and information supporting each use case.
The model showed where information originated, how it reached the AI service, where outputs were stored and which applications or business processes used those outputs.
The team considered:
- ✓personal, confidential and commercially sensitive information;
- ✓engineering drawings and intellectual property;
- ✓customer and supplier information;
- ✓training, reference and prompt data;
- ✓model outputs and generated documents;
- ✓identity and access paths;
- ✓system interfaces and automated data transfers;
- ✓storage locations and retention rules;
- ✓external hosting and processing locations;
- ✓dependencies on suppliers and cloud services.
This exposed risks that were not visible in the original project descriptions, including excessive access, unclear retention and supplier dependencies.
We assessed cyber and AI risks together
Rather than creating an isolated AI risk register, we connected AI-related risks with the company’s existing cyber and operational risk processes.
The assessment considered:
- ✓unauthorised access to AI services or connected systems;
- ✓disclosure of confidential or personal information;
- ✓manipulation of prompts, inputs or connected data sources;
- ✓inaccurate, incomplete or misleading outputs;
- ✓excessive reliance on automated recommendations;
- ✓unapproved changes to models or configurations;
- ✓loss of service or supplier availability;
- ✓weak logging and limited traceability;
- ✓failure to detect inappropriate use;
- ✓legal, contractual and reputational consequences.
The risk level depended on business impact, information sensitivity, user access, external exposure, supplier dependency and the degree of human oversight.
We reviewed the controls behind each use case
The presence of a policy or technical feature was not treated as proof that a risk had been addressed.
For each important control, we recorded:
- ✓the risk the control was intended to reduce;
- ✓the systems and use cases to which it applied;
- ✓the person responsible for its operation;
- ✓the evidence required to demonstrate that it worked;
- ✓the frequency of testing or review;
- ✓any dependency on manual activity;
- ✓any known limitation or exception;
- ✓the remaining risk after the control was considered.
Controls included access restrictions, data filtering, encryption, logging, human review, supplier assurance, output testing and incident reporting.
We introduced a proportionate approval process
The company did not want every small experiment to go through the same process as an AI solution used in production.
We introduced three assessment routes:
- ✓Low-impact use: limited data, no sensitive information and no material influence on business decisions.
- ✓Managed use: controlled business information, integration with internal systems or outputs used in operational work.
- ✓High-impact use: sensitive data, important business decisions, production dependencies or significant consequences if the output was wrong.
Each route had defined evidence, reviewers and approval criteria. This allowed low-impact ideas to progress without weakening scrutiny of more significant projects.
We introduced monitoring and change triggers
Approval was not treated as the end of the risk process.
A new review was required when:
- ✓a new source of data was introduced;
- ✓the solution was opened to additional users;
- ✓an external model or supplier changed;
- ✓the AI output began supporting a different decision;
- ✓a material security incident or data breach occurred;
- ✓testing identified a significant accuracy or control problem;
- ✓an important control stopped working;
- ✓a regulatory, contractual or customer requirement changed.
Automated notifications were used where reliable source data was available. Important decisions remained with the responsible business, security and data-protection owners.
We created reporting for management and project teams
Project teams needed to know what they had to complete before approval. Management needed a broader view of value, exposure and unresolved risk.
The reporting covered:
- ✓active, proposed and experimental AI use cases;
- ✓use cases involving sensitive or confidential information;
- ✓high-impact solutions and their accountable owners;
- ✓unresolved cyber and data-protection risks;
- ✓missing or ineffective controls;
- ✓supplier dependencies and outstanding assessments;
- ✓approvals, exceptions and review dates;
- ✓decisions required from management.
The reports showed why an issue mattered, who owned it, what action was planned and whether a management decision was required.
What we delivered
The client received:
- ✓a central inventory of AI use cases;
- ✓a connected model of AI solutions, business processes, applications, data and suppliers;
- ✓a coordinated method for assessing cyber, privacy and operational risks;
- ✓risk-based approval routes for different types of AI use;
- ✓defined business, technical and risk-owner responsibilities;
- ✓a control library with evidence and review requirements;
- ✓change triggers and reassessment rules;
- ✓exception and escalation procedures;
- ✓management and project-level reporting templates;
- ✓practical guidance for maintaining the model as AI use developed.
The project did not create another disconnected AI register. It connected AI initiatives with the information and risk processes the company already used.
The results
Within nine months, the company:
The figures describe the representative client scenario used in this case study.
What changed for the client
What we learned
Client comment
“Before this work, our AI initiatives were being discussed separately by different teams. The connected model helped us understand where each solution depended on sensitive data, important systems and external providers. We could support useful projects while being much clearer about the safeguards and ownership they required.”
This quotation is an illustrative example for the representative client scenario.
Conclusion
The company did not need a separate risk register for every AI experiment. It needed a clearer way to understand how each initiative fitted into the wider organisation.
By connecting AI use cases with business processes, data, applications, suppliers, controls and responsible owners, the company created a more practical basis for making decisions.
Business teams could explain the value they expected. Security and data-protection teams could identify the most important risks. Technical teams understood the controls they needed to implement. Management could see where AI created a useful opportunity and where unresolved exposure required a decision.
Most importantly, AI governance became part of the company’s established approach to cyber and business risk rather than a separate process operating alongside it.
Are you facing a similar problem?
AI initiatives often develop across different departments, tools and suppliers. Without a connected view, important relationships between AI, data, systems, controls and business processes can remain hidden.
Cybersecurity Analytics can help you:
- ✓identify AI use cases across your organisation;
- ✓connect AI initiatives with data, applications and business processes;
- ✓assess AI, cyber, privacy and operational risks together;
- ✓understand supplier and technology dependencies;
- ✓define proportionate controls and approval routes;
- ✓assign clear owners and review responsibilities;
- ✓introduce automated monitoring without removing human oversight;
- ✓give management a clearer view of AI-related business risk.
