Altiri1. How can we introduce AI tools without exposing confidential information?
Start by defining the intended use and the information involved. A tool suitable for summarizing public research will generally require additional security and privacy safeguards before it can be entrusted with the processing of internal documents, personal information, or client records.
Review how the AI service provider handles inputs and outputs, including retention, access, model training, deletion, and connections to other systems. Confirm the contractual terms and the settings that apply to your specific service plan. Document what users may enter, what they may share, and when a person must review the output.
A controlled pilot can help establish whether the tool is useful and whether the safeguards work in practice. Give the pilot program an owner, a defined user group, permitted data sources, and criteria for expanding or stopping it.
In recent engagements with mid-size organizations, we have worked with internal data governance committees and procedures to determine and authorize minimum necessary access to accomplish the objective, and implemented appropriate safeguards without unnecessary expense or delay.
The objective is to make an informed decision about a specific use, with safeguards that are appropriate to the information being processed, and potential consequences.
2. What should we have in place before approving an AI pilot?
An AI pilot should have a business purpose, an accountable owner, a defined scope, and an agreed way to evaluate both usefulness and risk.
Before approval, document:
- What the tool will do and who will use it.
- What information it will receive and where that information will go.
- How outputs will be checked before they affect people, business decisions, or other systems.
- What access and integrations the pilot requires.
- What success looks like and what would cause the pilot to stop.
- Who can approve changes or expansion.
For pilots with potentially significant consequences, bring together relevant stakeholders to review concerns before approval. Consider effects on hiring, safety, legal and regulatory obligations, financial decisions, and ethical responsibilities. Document material concerns, required safeguards, and unresolved decisions.
Record the approval and its conditions. A successful pilot should lead to a deliberate production decision, including ownership and ongoing review.
3. Who should own AI governance: IT, security, legal or business leadership?
Business leadership should establish accountability for AI governance, supported by clear responsibilities across the functions involved. The person responsible for an AI use case should understand its purpose, expected benefit, and consequences.
IT can evaluate architecture, integrations, and support. Security can assess access, information protection, and misuse. Legal and privacy specialists can address relevant obligations and contractual concerns. Business owners should determine whether the use is appropriate and whether its results are reliable enough for the intended purpose.
These responsibilities need a defined decision process. Specify who reviews a proposal, who approves it, who implements conditions, and who can accept remaining risk.
An organization does not necessarily need a new committee for every AI decision. Existing governance arrangements can work when their authority, expertise, and review criteria cover the proposed uses. Established IT change control procedures should also be employed before deploying to production.
4. How can we add AI governance to our existing cybersecurity and compliance program?
Begin by identifying which existing processes already address part of the problem. Vendor reviews, identity and access management, information classification, incident response, change management, and risk reporting can all contribute to AI governance.
Then identify what needs to be added or adapted. AI reviews may need to examine output reliability, human oversight, monitoring capability, logging and visibility into system behavior, periodic evaluation procedures, model or service changes, unintended disclosure through prompts and responses, and the consequences of automated actions.
For example, an existing vendor-review process can incorporate questions about provider training practices, retention settings, and model updates. An existing change process can require a new review when an AI tool gains access to additional information or systems.
The result should be a coordinated operating process with shared ownership and evidence. Reuse effective controls while addressing the risks that the existing program does not yet cover.
5. What should an AI governance consultant actually deliver?
An AI governance engagement should leave the organization with a defined process for deciding which AI uses are permitted, who approves them, what safeguards apply, and how those decisions are reviewed as circumstances change.
Depending on scope, deliverables may include an AI use-case inventory, assigned decision responsibilities, a review process, vendor and data-handling evaluations, practical usage guidance, and an implementation plan with owners and completion criteria.
Before engaging a consultant, ask who will implement the recommendations, how completion will be verified, and who will maintain the process afterward. A policy document is one deliverable; the engagement should also explain how the organization will put it into practice.
Altiri can help establish these processes and take responsibility for agreed implementation and ongoing program activities as needed.
6. When does a company need a fractional CISO rather than an assessment or technical service provider?
A fractional Chief Information Security Officer can be useful when an organization needs recurring security leadership but does not need, or is not ready to hire, a full-time executive.
An assessment provides findings at a point in time. A technical service provider delivers defined operational services. A fractional CISO can help leadership decide what to prioritize, coordinate work across those providers and internal teams, oversee the security program, and explain progress and remaining risk.
Typical triggers include unresolved assessment findings, competing security investments, customer assurance demands, unclear accountability, or an expanding business with more complex obligations.
The role should have defined responsibilities, access to decision makers, and a regular reporting cadence. Internal management retains authority over business decisions, budgets, and risk acceptance.
7. Can an outside consultant manage implementation and ongoing governance?
Yes. An outside consultant can take responsibility for defined program activities, coordinate implementation, maintain an action plan, prepare management reporting, and help teams collect evidence that agreed safeguards are operating.
The engagement should distinguish the consultant’s delivery responsibilities from decisions retained by management, such as approving budgets, accepting risk, and authorizing business use.
A useful scope identifies the activities the consultant owns, the internal counterparts who support them, the decisions requiring escalation, and how progress will be demonstrated. It should also address access to systems and records, dependencies on other providers, and continuity when the engagement ends.
Altiri can combine advisory support with ownership of agreed program activities, including coordination with existing staff and service providers.