The discussion around AI governance is no longer just theory.
Today, generative AI, copilots, and local automations are already part of the daily routine of business areas, data teams, and operations.
At the same time, the use of AI tools outside IT’s control is growing. This phenomenon has become known as Shadow AI.
That’s where the conversation about AI governance in companies meets a classic corporate Shadow IT problem, now powered by Python and AI.
What AI governance actually means in practice
AI governance in companies has become an urgent topic.
This means that it’s no longer about whether AI will be used, but how it will be used in a secure, auditable way and aligned with internal and regulatory norms.
For a broader understanding of the concept, see our guide on what AI governance means for enterprises.
In practice, AI governance has to deal simultaneously with:
-
data and privacy risks
-
operational and continuity risks
-
regulatory and reputational risks
Without this integrated view, a company may advance in AI initiatives, but remain exposed when incidents, audits, or board questions arise.
According to projections presented by Gartner, a significant share of companies is expected to suffer security or compliance incidents linked to Shadow AI by 2030, mainly due to unmonitored use of AI by employees.
As a result, the blind spot is that this Shadow AI doesn’t live only in SaaS apps or chat windows in the browser. It starts to turn into Python+AI code running directly on endpoints: notebooks, workstations, VMs, and servers close to business areas.
AI has become operational infrastructure
Generative AI tools now support tasks such as:
-
generating Python code to integrate internal systems
-
automating data processing and reporting routines
-
creating small agents that run queries, transformations, and daily outputs
In other words, AI already touches critical data, regulated systems, and sensitive processes.
When this happens without visibility and clear trails, AI governance becomes just another PDF document instead of a real control mechanism.
From Shadow IT to Shadow AI
Shadow IT is the use of technology outside the official IT umbrella.
In this context, Shadow AI is the new layer of this problem, now with artificial intelligence tools:
-
employees use AI without formal approval
-
decisions are influenced or automated with no clear trail
-
code is generated and adapted by AI with no review standard
In practice, this Shadow AI may start in the browser, but it quickly materializes as Python scripts running on users’ machines.
When this happens without inventory or monitoring, the organization loses control of:
-
which data is being processed
-
on which endpoints this is happening
-
who is behind those automations
Consequently, the problem becomes even more critical when this Shadow AI is implemented as Python scripts running directly on endpoints, often with access to sensitive systems and data.
Where Shadow AI hides: Python on endpoints
Shadow AI doesn’t show up only in cloud provider contracts or large AI projects.
A relevant part of it lives in the day-to-day of teams, in automations created to solve specific problems.
And in this day-to-day reality, Python on endpoints has become a privileged channel.

Scripts and agents generated by AI outside official pipelines
With generative AI, anyone with intermediate knowledge can ask:
“Create a Python script to pull data from our internal system, consolidate it in a spreadsheet, and send a summary by email every day.”
That script typically:
-
is saved in a local folder or on a VM
-
runs via a simple scheduler or command line
-
accesses internal APIs, databases, and network file shares
All of this often happens without going through official development, DevSecOps, or change management pipelines.
In practice, this creates a scenario where:
-
part of the company’s critical automation is in non-inventoried scripts
-
these scripts use AI to generate, adjust, or assist decisions
-
none of these flows shows up in traditional AI governance dashboards
Endpoints as the new blind spot
When people talk about AI governance, attention usually goes to:
-
AI models in the cloud
-
official integrations between systems
-
large applications with embedded AI
But endpoints are increasingly the place where:
-
Python scripts with AI are executed
-
personal and sensitive data is handled
-
credentials and tokens are stored with no standard
Without visibility into what runs on those endpoints, the company creates an operational blind spot.
This is exactly where Shadow AI, Python, and Shadow IT converge: Python+AI running at the edge, outside official governance.
Why the risk is greater in regulated industries
Sectors such as finance, healthcare, insurance, energy, and utilities usually have:
-
strong regulatory pressure
-
high volumes of sensitive data
-
intense dependence on automation
In these environments, the impact of Shadow AI in Python+AI on endpoints is even greater, because any misstep can translate into:
-
reportable incidents to regulators
-
administrative sanctions
-
material reputational damage
Global regulations and the need for inventory
Regulations such as GDPR, DORA (in the European financial sector), and operational risk standards point in the same direction:
-
require inventory of relevant systems and flows
-
test and prove operational resilience
-
maintain audit trails for important decisions and automations
In practice, this means AI governance cannot be just a set of principles.
It needs concrete data on:
-
where AI is running
-
which flows use Python+AI
-
how this connects to endpoints, systems, and people
AI Act: Governance Requires More Than Approved AI Tools
The EU AI Act is making AI governance an operational requirement rather than a policy exercise. As of August 2, 2026, the European Commission and national authorities have begun enforcing the AI Act, while transparency requirements for certain AI systems are also in effect. The regulation establishes a risk-based framework and introduces requirements around governance, transparency, AI literacy, cybersecurity, and traceability for applicable AI systems.
For enterprises, this reinforces an important principle: AI governance cannot stop at approving AI platforms or defining acceptable-use policies. Organizations also need to understand how AI is actually being used across their environments and maintain enough evidence to demonstrate that the appropriate controls are in place.
This becomes particularly relevant when AI-generated code is executed through Python on enterprise endpoints. A script created with an AI assistant may access internal databases, process sensitive information, call external APIs, or interact with AI services without ever becoming part of an official development pipeline. The governance challenge is therefore not limited to the AI model itself, but extends to the execution layer where business data and systems are actually accessed.
For organizations operating in regulated environments, this creates a practical requirement for visibility into:
- which AI-enabled scripts are running across endpoints;
- what data and systems those scripts access;
- which external services or AI APIs they communicate with;
- who executed them and when;
- what evidence exists to demonstrate that the activity remains within organizational policies.
The AI Act also makes AI literacy an explicit obligation for providers and deployers, requiring organizations to take measures to support the AI literacy of employees and others involved in operating and using AI systems.
The direction is clear: AI governance is moving from policy definition toward operational accountability. Enterprises need visibility into how AI is actually used, not only which tools have been approved.
Without Python + AI inventory on endpoints, there is no AI governance
The expression “AI governance” only makes sense if there is real visibility.
Without an inventory of Python+AI on endpoints, the company is governing only part of the problem.
The questions that expose the gap
A few simple questions help test the real level of AI governance:
-
Do you know on which endpoints Python is being executed today?
-
Do you know which scripts use AI models or AI APIs?
-
Do you know which data and systems those scripts access?
-
In an audit, can you show who ran what, when, and where?
If the answer is “no” or “more or less,” there is a governance gap.
This gap is precisely the combination of:
-
Shadow AI
-
Python on endpoints
-
lack of inventory and trail
Limitations of traditional tools
Traditional security and inventory tools were not designed for this scenario.
In general, they:
-
see installed applications, but not scripts that run sporadically
-
monitor traffic and events in central systems, but not local execution details
-
do not distinguish “generic Python” from Python+AI that touches sensitive data
As a result, a company may have:
-
formally approved AI policies
-
an active AI governance committee
-
well-produced reports for the board
But at the same time, it still fails to see a large portion of the real use of Python+AI on endpoints.
In practice, AI governance remains limited to what goes through official pipelines, ignoring what is already in production at the edge.
How BotCity Sentinel closes this governance gap
From here on, we get into the practical layer.
If the problem is Python+AI already in production on endpoints, it makes sense to have a specific agent for this context.
This is the role of BotCity Sentinel.
Python governance on enterprise endpoints for the AI era
BotCity Sentinel is designed to govern Python execution directly on enterprise endpoints, providing visibility into code that is already running in real, post-deploy environments.
The platform allows organizations to:
- identify where Python is being executed
- log real scripts and executions, not just installations
- understand which scripts interact with AI services
- establish policies for Python execution
- investigate and control scripts based on their actual behavior
Instead of relying on local perceptions or what has passed through official development pipelines, organizations gain an objective view of Python execution across their endpoints.
View by machine, user, and system
Sentinel organizes Python execution across three key dimensions:
- machine: which scripts ran there, how often, and for how long
- user: who executed what
- system and data: which systems, APIs, databases, or files were accessed
With this view, it becomes much easier to:
- pinpoint Shadow AI hotspots that turned into critical Python automations on endpoints
- prioritize risks based on sensitive data and regulated systems
- build a solid narrative for the board, auditors, and regulators
Besides that, Sentinel adds capabilities that allow organizations to move from simply observing Python execution to establishing a structured governance model around it.
- Policies and custom groups allow organizations to define execution policies according to teams, business units, or projects, applying controls based on operational context.
- Repository catalog provides a centralized view of approved Python scripts, including versions, ownership, and execution history, creating a structured reference for code used across the organization.
- Deep Python script instrumentation provides visibility into what happens during execution, including libraries, dependencies, external calls, database access, and interactions with services.
- Visible Mode and External Access support controlled access to relevant information for auditors, consultants, and partners without giving them full access to the environment.
- Script blocking adds an enforcement layer, allowing organizations to stop specific executions when a policy or identified risk requires immediate action.
This approach turns Python execution into an observable, auditable, and controllable layer of enterprise operations rather than leaving it outside the scope of existing governance processes.
Govern the Python execution layer of your AI strategy
AI governance cannot stop at approved models, SaaS applications, or formal AI initiatives. As AI becomes part of everyday operations, the code generated, adapted, and executed by employees becomes part of the governance perimeter as well.
BotCity Sentinel provides the visibility and control needed to govern that execution layer directly on enterprise endpoints, complementing the security and governance tools already in place.
See how BotCity Sentinel governs Python execution across enterprise endpoints.