By Dr. Kevin Shepherdson
In Part I, we discussed the growing governance gap created by low-code, no-code, and AI-powered software creation tools.
The central issue was simple: today, almost anyone can create an AI application. A business user can build a chatbot. A consultant can generate a workflow app. A manager can create an internal assistant. A non-technical creator can describe what they want in plain English and have the system produce an application, code, database structure, or even an autonomous agent.
That is powerful.
But it also creates a new risk: the ability to create has become much easier than the ability to govern.
Part I focused on this mismatch. We explored why governance matters, why creating is not the same as deploying responsibly, and why non-technical creators may not fully understand what their AI applications collect, store, generate, decide, distribute, or retain. We also discussed the “low-code maturity bypass” — where users jump quickly from experimentation to creation and deployment, without first developing the AI literacy, testing discipline, data governance awareness, or risk management capability needed to do so safely.
In Part II, we go deeper into what is often missed.
The issue is not only that people are creating AI applications quickly. The deeper issue is that many creators do not think in terms of the full data lifecycle.
They may see an app.
Governance professionals see something more: a system that collects data, stores data, generates outputs, influences decisions, distributes information, and eventually needs to be retired or decommissioned.
That is why lifecycle thinking matters.
The Data Lifecycle is Often Ignored
Most low-code and no-code creators think in terms of screens, prompts, workflows, forms, buttons, and outputs. They ask:
“Does the app work?” But AI governance requires a different question: “What happens to the data across the entire lifecycle?”
This is where an ISO 38505-style data governance lens becomes useful. It reminds us that every AI application is not just an interface. It is also a system that collects, stores, processes, generates, distributes, and eventually retires data.
For a creator, the app may appear simple. For example:
1. a customer service chatbot;
2. a HR screening assistant;
3. a contract summarisation tool;
4. a sales lead follow-up agent;
5. a compliance document reviewer;
6. a finance reporting assistant.
But behind the scenes, each of these tools may touch multiple points in the data lifecycle.
Collect: What Data Enters the App?
The first question is what data the app collects.
A creator may ask users to upload resumes, contracts, invoices, medical notes, customer complaints, internal reports, or meeting transcripts. They may not realise that the app is collecting personal data, confidential data, regulated data, copyrighted material, or commercially sensitive information.
In some cases, the creator may simply connect the app to a folder, spreadsheet, CRM, knowledge base, or email inbox without fully understanding what types of data are being exposed to the AI system.
The risk is not only whether the data is useful. The risk is whether the data is appropriate, lawful, accurate, consented, and necessary.
Store: Where Does the Data Go?
Once data enters the app, it may be stored in ways the creator does not fully understand.
The app may retain uploaded documents, chat histories, user prompts, generated outputs, logs, embeddings, temporary files, or API responses. Some data may sit in the platform’s cloud environment. Some may be stored by third-party model providers. Some may be cached or logged for debugging.
This matters because AI applications often create new repositories of risk.
A simple chatbot may become a storage location for sensitive employee questions. A document assistant may retain confidential client files. A workflow agent may store API keys, transaction records, or operational logs.
If the creator does not know what is stored, where it is stored, who can access it, and when it is deleted, the organisation has a governance problem.
Report: What Outputs Does the AI Produce?
The Report stage is where the AI generates outputs that users may read, copy, rely on, or act upon.
This may include summaries, recommendations, classifications, rankings, risk scores, code, advice, emails, reports, or explanations.
The danger is that AI outputs often look confident even when they are wrong. A contract summariser may miss an important clause. A compliance assistant may misstate an obligation. A coding assistant may generate insecure code. A finance assistant may produce a plausible but inaccurate explanation.
At this stage, the creator must ask:
How will the output be validated before someone relies on it?
If the answer is “the user will just check,” that may not be enough. The user must be qualified, given enough context, and empowered to challenge the AI output.
Decide: Does the App Influence a Decision?
This is where the risk increases sharply.
An AI app may start as a productivity tool, but quickly become a decision-support system.
A recruitment assistant may influence who gets shortlisted. A credit support tool may influence how a customer is assessed. A compliance triage tool may influence which issues are escalated. A customer service chatbot may influence whether a refund is granted. A sales agent may influence which leads receive follow-up.
The governance issue is not whether the AI makes the final decision. The issue is whether the AI shapes the human decision.
Once an AI app influences decisions affecting people, customers, employees, money, rights, or legal obligations, the organisation must consider the appropriate human oversight model:
human in the loop;
human on the loop;
human out of the loop.
But this cannot be a slogan. The human reviewer must be qualified, accountable, and able to intervene.
Distribute: Who Receives the Output?
Many risks only become visible when AI outputs are distributed.
An internal draft may be low risk. The same content published to customers, regulators, students, patients, or the public may create much higher risk.
Low-code creators may not appreciate how quickly distribution can scale. An app can be shared by link, embedded on a website, connected to a workflow, added to a customer portal, or made available across departments.
This raises important questions:
1. Who can access the app?
2. Who can see the outputs?
3. Can outputs be exported or forwarded?
4. Are users told that AI is involved?
5. Is there a review step before publication?
6. Can harmful or incorrect outputs spread quickly?
Distribution is where small mistakes can become visible incidents.
Dispose: What Happens When the App Is No Longer Used?
The final stage is often forgotten.
Low-code and no-code environments make it easy to create many apps quickly. But not every app is maintained. Some are abandoned. Some are replaced. Some continue running quietly. Some still retain data, logs, credentials, prompts, or user records long after their purpose has ended.
This creates disposal risk.
An abandoned AI app may become an unmanaged data repository. A forgotten workflow may continue calling APIs. A stale chatbot may answer questions using outdated policies. An old agent may still have access to systems it no longer needs.
Responsible AI governance must therefore ask:
How will this app be retired, archived, disabled, or deleted?
Without disposal controls, yesterday’s experiment can become tomorrow’s breach.
Why Lifecycle Thinking Matters
The data lifecycle lens changes how we view low-code and no-code AI creation.
The question is no longer only: “Can the creator build the app?” but rather : “Can the organisation govern what the app collects, stores, produces, decides, distributes, and eventually disposes of?”
This matters because many AI failures do not begin at the point where harm becomes visible. They begin much earlier — when data is collected without proper authority, stored without adequate protection, used to generate outputs without validation, or deployed into decisions without appropriate oversight.
Low-code and no-code tools accelerate creation.
Lifecycle governance ensures that creation does not become uncontrolled exposure.
