By Dr. Kevin Shepherdson
The low-code and no-code movement has lowered the barrier to software creation. But it has not automatically raised the level of AI governance, cybersecurity awareness, data protection knowledge, or domain expertise among creators.
That is why governance matters.
Governance is not about stopping innovation or creating unnecessary paperwork. It is about making sure that what is created can be safely deployed, responsibly used, properly monitored, and eventually retired. Without governance, a simple AI application can unintentionally become a data collection system, a decision-support tool, a compliance risk, or a security exposure point.
Consider a simple HR example. A non-technical user creates an AI-powered recruitment assistant to screen resumes and generate interview shortlists. The app may appear useful because it saves time. But if no one checks the training data, prompt rules, selection criteria, or output logic, the system may quietly reproduce bias, exclude qualified candidates, or generate discriminatory recommendations. The creator may think they have built a productivity tool. In reality, they may have deployed a high-risk employment decision-support system.
Or take a simple customer service example. A business user creates an AI chatbot to answer customer queries based on uploaded company documents. The chatbot works well in testing. But after deployment, it may reveal internal pricing, misstate refund policies, provide incorrect advice, or retain customer prompts containing personal data. The creator may not realise that the app is now collecting, storing, generating, and distributing information across the organisation’s data lifecycle.
This creates a dangerous mismatch.
A user may be able to create an AI-powered application, but may not understand:
1. what data the application collects;
2. where the data is stored;
3. whether personal or confidential data is involved;
4. whether copyrighted content is being used;
5. how the AI model generates its outputs;
6. whether the application is making or influencing decisions;
7. whether users may rely on inaccurate outputs;
8. how much the application costs to run;
9. what happens when the application is no longer used.
In traditional software development, technical teams usually handled these questions. In the new AI application economy, many of these decisions are being made by non-technical creators, citizen developers, and even developers who may not understand the full domain context.
That is where the risk begins.
The Low-Code Maturity Bypass
Many AI creators jump straight into building.
They move quickly from: “I have an idea” to: “I have an app” to: “Let’s deploy it.”
But responsible AI adoption should not work that way.
A useful way to understand the risk is through an AI maturity framework. The danger with many low-code and no-code tools is that they allow users to bypass the maturity journey. They make it easy to move from experimentation to creation and deployment, even when the creator has not yet developed the AI literacy, governance awareness, data discipline, or testing capability needed to do so safely.
Stage 0: Freemium Trap
At this stage, users experiment casually with free or public AI tools.
For low-code and no-code creation, this may mean a creator uploads proprietary documents, customer lists, HR records, internal policies, product roadmaps, contracts, or source code into a free AI app builder “just to test what it can do.”
The creator may not realise that they are already creating risk. Sensitive information may be exposed to third-party platforms. Prompts and uploaded files may be stored. Data may be reused for service improvement depending on the platform’s terms. The organisation may also have no inventory of what has been uploaded, by whom, and for what purpose.
The risk at Stage 0 is not that the user is malicious. The risk is that experimentation happens before governance exists.
Stage 1: Use
At this stage, users begin using GenAI tools more formally for productivity tasks.
But many creators have not spent enough time at this stage to understand what GenAI can and cannot do. They may not yet appreciate hallucination, prompt sensitivity, context limits, data leakage, model inconsistency, copyright issues, or the difference between a helpful draft and a reliable output.
Instead of learning how to use AI responsibly, they jump straight into creating AI applications.
This is like asking someone who has barely learned to drive to start designing traffic systems. They may understand the visible interface, but not the underlying risks.
For low-code and no-code creators, Stage 1 should be where they learn AI literacy: how LLMs behave, when outputs fail, what needs human review, and why not every impressive answer is trustworthy.
Stage 2: Create
At this stage, creators start building custom AI apps, assistants, workflows, or agents.
This is where low-code and no-code tools are strongest. They make creation fast, visual, and exciting. A user can create a chatbot, HR assistant, compliance checker, knowledge assistant, lead generator, customer support tool, or workflow agent without writing much code.
But creation introduces new responsibilities. The creator must now think about data sources, access rights, prompts, system instructions, model choice, tool connections, user permissions, logging, testing, and output validation.
The danger is that the tool may make the app look complete before the governance thinking is complete. An AI app that “works” in a demo may still be insecure, biased, inaccurate, expensive to run, or unsuitable for real users.
Increasingly, the Create stage is no longer limited to building simple apps or chatbots. Many low-code and no-code platforms now allow creators to design agentic workflows or autonomous agents simply by giving instructions in natural language. This is where excitement can quickly outrun understanding. A creator may define an agent to “research competitors,” “follow up with leads,” “summarise contracts,” or “update records” without fully understanding how the agent plans, reasons, selects tools, calls APIs, handles exceptions, or decides when to stop.
The app may look easy to create, but the underlying behaviour can be complex, unpredictable, and highly dependent on the quality of prompts, permissions, data access, and workflow design.
Stage 3: Deploy
At this stage, the AI app is placed into a live workflow. This is where risk changes significantly.
The app is no longer a prototype. It may now interact with employees, customers, students, patients, vendors, or the public. It may influence real decisions, generate advice, update records, send notifications, or trigger downstream actions.
For low-code and no-code apps, deployment can happen too easily. A creator may publish a link, embed the app into a website, connect it to a CRM, integrate it with email, or allow an agent to call APIs without fully understanding the consequences.
This is the point where “I built something useful” becomes “the organisation is now relying on this system.”
Deployment requires testing, human oversight, access control, escalation rules, audit logs, and clear accountability.
Stage 4: Govern
At this stage, the organisation applies formal governance.
This includes risk classification, approvals, data protection review, cybersecurity review, AI policy alignment, documentation, accountability, audit trails, and monitoring.
The problem is that governance is often introduced too late.
By the time GRC, legal, privacy, or security teams discover the AI app, it may already be used by staff or customers. It may already be collecting data, generating outputs, influencing decisions, or creating operational dependency.
For low-code and no-code AI, governance cannot be an afterthought. It must be embedded before deployment, not only after an incident occurs.
Stage 5: Manage
At this stage, AI becomes part of the organisation’s operating environment.
The focus shifts from creation to long-term management.
The organisation must monitor performance, accuracy, cost, model drift, user feedback, incidents, access rights, prompt changes, policy changes, vendor changes, and data retention. It must also know when to retire, update, or decommission an AI app.
This stage is often neglected in low-code environments.
Creators may build many apps but fail to maintain them. Some apps become stale. Some continue storing data after their purpose has ended. Some rely on outdated prompts or documents. Some continue consuming tokens and API calls without anyone reviewing their value. Others become shadow systems that no one officially owns.
The risk at Stage 5 is not just poor performance. It is unmanaged dependency.
The Maturity Gap
The central problem is this:
Low-code and no-code tools make it easy to reach Stage 2 Create and Stage 3 Deploy, even when the organisation is still operating with Stage 0 or Stage 1 maturity.
That creates a maturity gap.The creator can build faster than the organisation can govern.
This is why AI app creation needs to be tied to maturity. The more powerful the app becomes, the more governance discipline is required.
1. A simple internal drafting assistant may require light controls.
2. A customer-facing chatbot requires stronger controls.
3. An HR screening assistant requires even stronger controls.
4. An autonomous agent that updates systems, sends messages, or triggers actions requires the highest level of oversight.
The question is no longer simply: Can we create this? The better question is: Are we mature enough to deploy and manage this responsibly?
