Internal AI Policy: What Enterprises Must Do Before Drafting One
Before drafting an internal AI policy, enterprises should map AI use, data flows, decision rights, monitoring controls, and group-versus-OpCo responsibilities. Learn the groundwork needed for a workable policy.
Lewis Ho
Many companies begin in the wrong place when they decide they need an internal AI policy.
A request goes to Legal. A template is pulled from the internet or borrowed from another company. A set of familiar warnings is added: do not enter confidential data into public tools, do not rely on outputs without review, keep human oversight in place. The document is approved, circulated, and filed.
That sequence feels responsible. In many organizations, it is also where the policy starts to lose practical value.
An internal AI policy should not be the first step in governance. It should come after an enterprise has identified how AI is already being used, where legal responsibility sits, which decisions require human control, and whether the business can actually monitor the rules it wants employees to follow.
This is particularly important for companies in Hong Kong. Large enterprises here often operate through multiple legal entities, across Hong Kong and Mainland China, with different business lines, different technical maturity levels, and different regulatory obligations. A policy drafted before those realities are mapped will usually be too vague to guide anyone or too rigid to support actual operations.
A good internal AI policy should be the final expression of groundwork already done. Before a single sentence is written, an enterprise needs to answer three questions. Where is AI already operating? Where must human judgment remain? And can the controls the company wants to promise actually be enforced?
Why Internal AI Policy Design in Hong Kong Requires Preparation First
For many enterprises, the first challenge is structural. The business sees itself as one group, one brand, one strategy, and its data can be treated as if it belongs to one system. But in legal terms, its operating entities are often separate. That matters when customer data, employee data, operational data, and AI tools begin to interact.
In Hong Kong, data collected for one purpose by one business unit cannot simply be pooled and reused for another AI initiative elsewhere in the group on the theory that “we are all one company.” The structure on the org chart may look unified. The legal responsibilities are not.
That gap between organizational instinct and legal reality is where bad AI policy usually begins. A generic group-wide AI policy may sound disciplined, but if it assumes unrestricted internal data sharing, uniform workflow design, or a single level of risk tolerance across the enterprise, it will be wrong before it is even implemented. A business unit cannot assume that data collected by one entity can automatically be reused by another for AI training, model tuning, analytics, or workflow automation simply because both sit under the same parent company. Group structure does not eliminate legal boundaries. If those boundaries are ignored, the policy may authorize practices the underlying legal framework does not support.
Hong Kong also adds a second layer of pressure: accountability. AI is no longer just a technology issue. It can affect privacy compliance, regulated workflows, outsourcing arrangements, board oversight, risk management, and public disclosures. Senior management and boards do not need a broad statement that the company uses AI responsibly. They need to know where AI is used, what controls apply, who is accountable, and how exceptions are handled.
That is why internal AI policy development should be treated as a governance exercise, not as a standalone drafting task.
1. Identify Where AI Is Already Being Used
The first step before writing an internal AI policy is to identify actual AI use across the enterprise.
Most organizations have two versions of reality. The first is the formal version shown in procurement files, technology roadmaps, and executive presentations. The second is the operational version found in day-to-day work. Employees use public and embedded AI tools to save time, improve output, and move faster. Business teams may adopt tools before formal approval catches up. Vendors may add AI features into existing products without much internal visibility.
This gap matters because an enterprise cannot govern what it has not identified.
Nevertheless, the starting point should be an AI inventory that covers more than just approved systems. The company needs to know which external tools are being used, by whom, on what data, for what purpose, and with what degree of autonomy. It also needs to know which of these tools are formally approved, which are embedded inside third-party platforms, and which have emerged informally through employee behavior.
The inventory should also distinguish between two different types of AI use.
The first is advisory AI or generative AI (Gen AI). These are tools that generate text, code, summaries, recommendations, or analysis, but where a human still decides whether and how to act on the output. The second is executory or agentic AI. These are systems that trigger actions, move information, update records, change pricing, route tasks, or interact with other systems with limited or no prior human approval.
This distinction matters because the risk profile is different. A human using Gen AI to draft internal notes presents one kind of risk. An AI-enabled workflow that affects pricing, procurement, customer outcomes, or regulated decisions raises another. A workable internal AI policy needs to reflect that difference from the start.
2. Identify Where Human Judgment Must Remain
Once an enterprise has identified where AI is being used, the next step is to determine where human judgment must remain.
This is where many AI policies become too general. They say there must be human oversight, but they do not define what that means in practice. They do not specify where review is required, who must approve the output, when escalation is needed, or which decisions may never be delegated.
That level of precision matters.
A useful pre-drafting exercise is workflow mapping. For each high-value or high-risk AI use case, the business should trace the process from data input to final action. Where does data enter the system? Where is AI used? At what point does an output become a business act, such as a customer communication, a pricing change, a procurement action, a recommendation, a contract draft, or an internal employment decision?
Those decision points should drive the policy.
Different business functions will require different levels of human control. Customer service, marketing, HR, legal, procurement, finance, and regulated business units should not all be governed in exactly the same way. A single rule for all AI use is rarely practical in a diversified enterprise.
This is especially relevant in Hong Kong groups with regulated or listed businesses. In those settings, senior management may need evidence that the company has identified where AI can support staff, where it can operate within limits, and where a human must retain final authority.
Before drafting an internal AI policy, the company should therefore decide:
which AI uses are advisory only
which uses require approval before action
which workflows can operate within defined thresholds
which decisions must always remain with a named human role
which activities require escalation, logging, or secondary review
Without that work, policy language about oversight remains too abstract to guide conduct or support governance.
4. Separate Group-Level Governance From Operating Company Responsibilities
Large enterprises often need more than one layer of governance.
The holding company usually owns enterprise risk appetite, group standards, disclosure posture, and escalation thresholds. Operating companies understand the local workflows, business realities, systems, vendors, and regulatory requirements that apply in practice.
An internal AI policy works better when that split is acknowledged from the outset.
At group level, the company can define baseline principles: prohibited uses, enterprise data boundaries, escalation triggers, board reporting expectations, and approval requirements for high-risk AI deployment. At operating company level, those principles can be translated into business-specific rules: what tools are allowed, what data can be used, what review steps apply, what local legal requirements must be met, and who can approve exceptions.
This approach is particularly useful where an enterprise includes multiple sectors or spans Hong Kong and Mainland China. A uniform policy may look neat, but it often fails to reflect how the enterprise actually works.
5. Build a Core Policy With Business-Specific Appendices
A single enterprise AI policy is rarely enough for a diversified company.
Different business units use AI in different ways. Their regulatory exposure, operational speed, risk tolerance, and customer impact vary widely. A group-level document should set common rules, but detailed controls often need to sit elsewhere.
A more practical structure is a two-tier framework:
a group core policy covering common standards, governance principles, prohibited uses, escalation, and enterprise-level controls
business unit or divisional appendices covering workflow-specific rules, approval thresholds, local compliance issues, and operating procedures
This structure supports consistency without forcing every part of the enterprise into the same model. It also makes policy maintenance easier as AI use expands.
For companies in Hong Kong, this is often the most realistic way to align listed-company governance, legal entity separation, local regulatory obligations, and business-level execution.
6. Map Cross-Border Data Flows Before Writing Rules
For Hong Kong enterprises, internal AI policy drafting becomes much harder once data moves across borders.
A company may have teams in Hong Kong, operations in Mainland China, shared cloud infrastructure, regional service providers, and group-wide analytics initiatives. On paper, that may look like standard enterprise architecture. In practice, it raises questions about data transfer, storage, processing, access rights, and regulatory obligations.
Before drafting internal AI rules, the company should map:
which entities control which data
which data sets move between group companies
which AI tools and vendors process that data
where those systems are hosted
whether onward transfers occur
which business functions rely on cross-border processing
This work matters because policy language can easily outpace legal and technical reality. A company may write an internal rule permitting certain AI uses, but the actual infrastructure, vendor arrangement, or transfer pattern may create constraints that the policy does not reflect.
For Hong Kong enterprises with Mainland exposure, this mapping exercise is essential before any internal AI policy is finalized.
7. Form a Pre-Drafting Working Group
Internal AI policy should not be drafted by Legal alone.
A workable policy needs input from the people who understand the business process, the systems, the data, the controls, and the legal exposure. In practice, that means the pre-drafting stage should include a cross-functional working group.
The core participants usually include:
Business unit leaders, who understand workflows, commercial priorities, and day-to-day use cases
Legal and compliance, who translate external obligations into internal rules
IT, information security, and data governance, who understand data movement, access controls, monitoring, and incident response
AI, engineering, or product teams, who know what the systems can do and what can be enforced technically
Risk, internal audit, or governance teams, where board reporting or regulated oversight is relevant
The purpose of this group is not to add process for its own sake. It is to make sure the eventual policy reflects actual operations and can be applied in the business.
Without that groundwork, companies usually face one of three problems:
the policy does not match the systems in production
the policy is so restrictive that employees work around it
the policy creates comfort at senior level without improving actual control
What Hong Kong Enterprises Should Do Before Drafting an Internal AI Policy
Before drafting an internal AI policy, a Hong Kong enterprise should complete the following groundwork:
Create an AI use inventory across approved tools, employee use, embedded vendor tools, and automated workflows
Classify AI use cases by advisory, assistive, or executory function
Map decision points to determine where human review, approval, or override must remain
Assess monitoring capability for logging, review, escalation, and incident investigation
Define governance split between group-level oversight and operating company implementation
Design a policy structure with a core group policy and business-specific appendices where needed
Map cross-border data movement before approving internal rules on AI use
Establish a cross-functional working group before drafting begins
These steps do not delay governance. They make governance real.
An internal AI policy should be the result of groundwork, answering the key questions. Where is AI already being used? Which legal entity controls the data? Which decisions require human approval? What can the business actually monitor? Which rules belong at group level, and which need to be handled by the operating companies?
Once those questions are answered, drafting becomes much easier. More importantly, the policy is more likely to reflect how the business actually operates.
That is what makes an internal AI policy useful: not the fact that it exists, but the fact that it is built on a structure the enterprise can defend, implement, and maintain.
1. What should a Hong Kong company do before drafting an internal AI policy?
Before drafting an internal AI policy, a Hong Kong company should identify where AI is already being used, classify use cases by risk and function, map where human review must remain, assess whether controls can be monitored, and review how data moves across legal entities and borders. For larger groups, it is also important to separate group-level governance from operating company implementation.
2. Why is a template AI policy not enough for Hong Kong enterprises?
A template AI policy is usually too general to reflect the legal, operational, and cross-border realities of a Hong Kong enterprise. Many groups operate through separate legal entities, rely on different vendors and systems, and face different regulatory obligations across business lines. Without mapping those differences first, the policy may be difficult to enforce or may fail to address the areas of highest risk.
3. How should a Hong Kong enterprise structure its internal AI governance framework?
A practical approach is to adopt a layered structure. The group should set baseline rules on risk appetite, prohibited uses, escalation, and data boundaries. Business units or operating companies should then apply those rules through more specific procedures covering approved tools, decision thresholds, human review points, and local compliance requirements. This allows consistency across the enterprise without ignoring operational differences.