Who should be accountable for approved AI tool settings in the enterprise?

Accountability should sit with the function that owns acceptable use and data risk, usually in partnership with security, privacy, and identity teams. If staff can change training, retention, or privacy modes without oversight, the organisation does not have a controlled AI usage model.

Why This Matters for Security Teams

Approved AI tool settings are not a minor configuration detail. They decide whether prompts, outputs, logs, and uploaded data stay inside an organisation’s risk boundary, or drift into unmanaged retention and exposure. Accountability matters because settings such as training opt-out, external sharing, audit logging, and data residency can create security, privacy, and legal consequences long before an incident is visible. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful reference for assigning control ownership, especially where configuration and monitoring intersect.

The most common failure is not a lack of policy, but a gap between policy and who can actually change the setting. If business users can enable new connectors, relax retention, or switch on model training for uploaded content without review, the enterprise has delegated risk without delegating responsibility. That creates a false sense of governance, particularly in shadow AI scenarios where approved tools are used outside central oversight. In practice, many security teams encounter this only after sensitive data has already been entered into a tool that was never configured for the organisation’s risk profile.

How It Works in Practice

Operational accountability should be assigned to the business or operational function that owns the use case, with clear control points for security, privacy, legal, and identity governance. In most enterprises, that means the tool owner or service owner is responsible for deciding the approved settings, while security defines the baseline, privacy validates data handling, and identity teams ensure the right users and service accounts can change or administer the tool. This is consistent with the broader control logic in NIST AI Risk Management Framework, where governance and accountability must be explicit rather than assumed.

A practical operating model usually includes:

• Named ownership for each approved AI tool, including who signs off on configuration changes.
• Standard settings for training use, content retention, telemetry, plugins, and external sharing.
• Change control for any setting that affects confidential, regulated, or customer data.
• Logging and periodic review so administrators, not end users, can verify what changed and when.
• Conditional access or role-based controls for high-risk settings, especially where privileged users can override defaults.

For tools that support agentic workflows, accountability should also cover what the AI system can do on behalf of a user or process. That is where settings become identity-adjacent: if an AI tool can read mail, retrieve records, or trigger actions, the organisation needs a defined approval path for both the tool configuration and the delegated authority behind it. Guidance from CISA AI Security resources is helpful here because it reinforces the need for operational controls around AI use, not just policy statements.

These controls tend to break down when a tool is deployed through a department-level subscription or embedded in a workflow platform, because administration is split across multiple owners and no single group can enforce the baseline.

Common Variations and Edge Cases

Tighter control over AI settings often increases operational overhead, requiring organisations to balance speed of adoption against assurance. That tradeoff is especially visible when teams want rapid experimentation with new models or copilots, but governance requires review before any setting can affect data handling or retention. There is no universal standard for this yet, so current guidance suggests using a risk-tiered approach rather than treating every AI tool the same.

High-risk cases need stronger accountability. If the tool processes customer data, regulated data, or internal intellectual property, the approval owner should be closer to the business process and supported by privacy, security, and legal review. If the tool is used by a technical team with privileged access, identity governance should be involved because configuration settings can effectively become a form of delegated privilege. In environments subject to formal governance expectations, ISO/IEC 42001 can help organisations structure responsibility for AI management systems, even though implementation will vary by maturity and regulatory pressure.

The edge case is consumer-style AI tools adopted informally by staff. In those environments, the approval question is often moot because no enterprise owner exists. The control objective then becomes removing ambiguity: either bring the tool under enterprise governance with explicit settings and ownership, or classify it as unapproved and block it. Where neither path is taken, accountability remains diffuse and the risk model fails at the point of use.

Related resources from NHI Mgmt Group

• Who should be accountable for AI agent actions in enterprise systems?
• Who should be accountable for agentic AI security standards in enterprise programmes?
• Who is accountable when an AI CLI tool turns a prompt into system-level access?
• Who is accountable when AI tool use happens through unmanaged browser sessions?