ISO/IEC 42001

Adding AI to software is easy.

Managing it responsibly throughout its lifecycle is harder.

LiteByte uses ISO/IEC 42001:2023: Artificial Intelligence Management System as a reference framework for the way we govern, develop, integrate, deploy and operate material AI systems.

ISO 42001 looks beyond whether an individual AI feature works. It considers the management system around AI: who is accountable, how risks and impacts are assessed, what information and resources are used, how suppliers are managed, what evidence is required before deployment, and how AI systems continue to be monitored and improved afterwards.

For LiteByte, that creates a simple principle:

AI should not enter production simply because the model can produce a convincing answer. There should be a defined purpose, accountable owners, documented requirements, evidence from testing and a plan for operating it responsibly once it is live.

Clear purpose and responsibility

What is the AI supposed to do, and who is responsible for it?

Before developing material AI functionality, we establish its intended purpose, expected users, operating context and the responsibilities of the organisations involved.

That is particularly important when integrating third-party models.

LiteByte may design and build the application while a provider such as OpenAI, Anthropic, Microsoft or another supplier develops and operates the underlying model. The client may control the business purpose and data, while LiteByte controls the surrounding application, prompts, integrations, permissions, testing and deployment.

We document those boundaries rather than treating "the AI" as one undifferentiated system.

ISO 42001 specifically expects responsibilities across the AI lifecycle to be understood between organisations, customers, suppliers and other third parties.

Risk and impact before development

What could happen if the AI gets it wrong?

Material AI projects are assessed before production use.

We consider the intended purpose alongside potential consequences for users, affected individuals and the wider context in which the system will operate.

Depending on the use case, that can include:

• incorrect or misleading outputs;
• privacy and information-security risks;
• harmful bias or unfair outcomes;
• inappropriate automated decisions;
• insufficient human oversight;
• financial or operational consequences;
• safety implications;
• misuse outside the intended purpose; and
• foreseeable impacts on individuals or groups.

The level of assessment is proportionate to the system.

An internal summarisation tool should not require the same assurance as AI influencing healthcare, employment, financial or other consequential decisions.

ISO 42001 requires organisations to establish a process for AI system impact assessment and to retain and update those assessments where appropriate.

Defined requirements before we build

What does acceptable AI performance actually mean?

AI requirements should be defined before the team decides the system is ready.

Depending on the project, that can include requirements for:

• output quality and reliability;
• acceptable error rates;
• security and privacy;
• human oversight;
• explainability and transparency;
• performance;
• appropriate use of data;
• operational constraints; and
• release criteria.

These requirements then inform development and testing.

The objective is to avoid a common AI failure mode:

Build something impressive, then decide afterwards what "good enough" means.

ISO 42001 expects AI system requirements and specifications to be documented and carried through the system lifecycle.

Responsible development

Is AI being engineered as part of a system rather than treated as a black-box API?

Our development process considers the complete AI-enabled application.

That may include:

• model and provider selection;
• prompts and system instructions;
• retrieval and knowledge sources;
• tool and function permissions;
• application logic;
• data flows;
• human interaction;
• testing;
• security controls;
• deployment architecture; and
• fallback behaviour.

Where LiteByte uses a third-party foundation model, we do not pretend to control how that model was originally trained.

We focus our assurance on the parts we actually control and document the provider-controlled elements as dependencies and limitations.

Where LiteByte is responsible for training, fine-tuning or managing AI-specific datasets, additional data-quality, provenance and preparation controls become relevant.

Data and AI resources

What information and resources does the AI depend upon?

AI systems depend on more than code.

Depending on the architecture, LiteByte documents relevant resources such as:

• AI models and APIs;
• data and knowledge sources;
• evaluation datasets;
• retrieval systems;
• development and testing tools;
• cloud and computing resources; and
• the human expertise required to develop or oversee the system.

For RAG and other knowledge-based systems, this can include considering where source information came from, how current it is, whether it is suitable for the intended purpose and how access permissions are maintained.

ISO 42001 explicitly treats data, tooling, computing resources and human expertise as resources that need to be understood across the AI lifecycle.

Verification before deployment

What evidence do we have that the system is ready?

Material AI functionality is evaluated before production use.

We define appropriate verification and validation activities for the particular system rather than relying solely on demonstrations or provider claims.

Depending on the risk, testing can include:

• representative user scenarios;
• accuracy and output-quality evaluation;
• hallucination and factuality testing;
• edge cases;
• malicious or unexpected input;
• prompt injection;
• security and privacy;
• tool and permission boundaries;
• harmful bias;
• human-review workflows;
• provider/API failure; and
• fallback behaviour.

Defined release criteria are reviewed before deployment.

Where requirements are not met, the response may be to improve the system, narrow its intended use, add safeguards or decide that the AI should not be deployed in its current form.

Human oversight

Where does human judgement remain necessary?

Automation does not automatically improve a system.

For each material AI use case, we consider:

• whether AI output requires human review;
• whether a person must approve an action;
• whether the system can be overridden or stopped;
• how uncertain or exceptional cases are escalated; and
• whether fully automated decision-making is appropriate at all.

The appropriate level of human involvement depends on the consequence of an error.

A low-risk internal productivity tool may require little intervention.

A system influencing a consequential decision may require explicit human authority before the output can affect someone.

ISO 42001's implementation guidance specifically treats human oversight as part of responsible AI development and use.

Transparency and useful information

Do the people relying on the AI know what they need to know?

AI documentation should be useful to the people operating or depending on the system.

Depending on the product, that can include:

• what the AI is intended to do;
• when AI is being used;
• important limitations;
• instructions for use;
• human-review requirements;
• performance expectations;
• how to override or stop the system;
• known risks; and
• how to report a problem.

Different audiences need different information.

A developer maintaining the integration needs technical documentation.

A staff member reviewing AI recommendations needs operational guidance.

An end user may simply need to understand that AI is involved and how much reliance should be placed on its output.

ISO 42001 specifically requires organisations to determine and provide relevant information to users and other interested parties.

Third-party AI providers

Using somebody else's model does not outsource responsibility for our implementation.

Most modern AI products depend on external providers.

When LiteByte integrates third-party AI services, we consider:

• what the provider supplies;
• what LiteByte remains responsible for;
• data sent to the provider;
• known limitations;
• contractual and privacy requirements;
• provider/model changes;
• available documentation and assurance;
• operational dependency; and
• how the application behaves if that service fails or changes.

A highly capable foundation model can still be integrated badly.

Responsible AI therefore includes both the model and the engineering decisions made around it.

ISO 42001 explicitly requires organisations to consider suppliers, customer expectations and allocation of responsibilities across the AI supply chain.

Operation, monitoring and change

What happens after the system goes live?

AI assurance does not end at deployment.

Depending on the application, ongoing operation can include monitoring:

• output quality;
• system failures;
• provider availability;
• unexpected behaviour;
• security events;
• model or provider changes;
• user complaints;
• human overrides;
• performance deterioration; and
• use outside the system's intended purpose.

Material changes can trigger reassessment and regression testing.

That is particularly important when using externally managed models because AI behaviour can change even when LiteByte's application code has not.

ISO 42001 explicitly expects ongoing system and performance monitoring, maintenance, updates and appropriate operational records.

Incidents and concerns

Can people raise concerns when something is not working as intended?

Material AI systems need a route for issues to be identified and escalated.

Depending on the context, that can include:

• users reporting incorrect or harmful behaviour;
• clients raising concerns;
• internal engineering escalation;
• security or privacy incidents;
• operational failures; and
• unexpected impacts discovered after deployment.

Significant incidents and concerns are investigated and used to inform corrective action and future development.

AI risk management should be capable of learning from production rather than assuming the original assessment will remain correct forever.

Our AI lifecycle

For material AI systems, our approach can be summarised as:

Define

Establish the purpose, requirements, responsibilities, resources and intended use.

Assess

Understand the risks, affected parties and potential impacts before proceeding.

Build

Develop the complete AI-enabled system with appropriate controls, human oversight and documentation.

Verify

Test the system against defined requirements and release criteria.

Deploy

Make an explicit production decision based on the available evidence and remaining risk.

Operate

Monitor performance, manage suppliers and changes, respond to incidents and keep documentation current.

Improve

Use evidence from operation, testing, incidents and changing requirements to continually improve how AI is managed.

What alignment means at LiteByte

ISO/IEC 42001 gives us a framework for managing AI as an organisational and engineering responsibility rather than treating individual AI integrations in isolation.

For material AI systems, we establish:

why the AI exists;

who is accountable for each part of it;

what requirements it must meet;

what risks and impacts need to be managed;

what evidence is required before deployment;

and how it will continue to be operated responsibly afterwards.

We support that process with documented project assessments, engineering evidence, technical documentation and ongoing system records.

That creates a simple rule:

We do not treat connecting to an AI model as the completion of an AI system. The model is one component. Responsible deployment includes the architecture, data, people, suppliers, controls, evidence and management processes around it.