### Context Pre-GA our AI features can be turned off, by not enabling the experimental/beta toggle in the namespace setting (on GitLab.com) or the instance level setting (SM). Once we release features to GA this toggle no longer applies. For Code Suggestions we have a separate toggle in the same settings. Note, this epic is about addressing the needs of data owners to protect their sensitive data. There is another need that is NOT the scope of this epic:controlling who may use the AI. ### Problem Customers want to control which of their data can and cannot be sent to an external LLM service. It seems the would like to control that on the project/sub-group/group levels. #### Evidence * [Feedback from the customer success team](https://gitlab.com/gitlab-org/gitlab/-/issues/423333#note_1553283703 "Gate access to Duo AI features based on user provisioning ONLY"): Do customers need control over if AI is used or if non-GA features are used by their employees or in their projects? * [UR Problem validation: AI Settings and Gatekeeping of AI & experiment features](https://gitlab.com/gitlab-org/ux-research/-/issues/2509#note_1680260555 "Problem validation: AI Settings and Gatekeeping of AI & experiment features") * https://gitlab.dovetail.com/projects/3sJJ0PN4zVzkRxmfZgYCyq/v/S6sewoN6NcPqn5jKvaAna * [Engineering perspective](https://gitlab.com/gitlab-org/gitlab/-/issues/434802#note_1696765732 "Enable Duo Chat for self-managed") ### Related work / pre-work / potential synergies * The code suggestions team has started an issue https://gitlab.com/groups/gitlab-org/-/epics/11950+ to consider more fine grained access control for Code Suggestions but there seems to be no good reason to apply this only to Code Suggestions * There are a lot of design proposals how to address this problem: https://gitlab.com/gitlab-org/gitlab/-/issues/413290+ * It makes sense to bundle our AI features and collectively allow or collectively forbidding its use on specific data: https://gitlab.com/gitlab-org/gitlab/-/issues/435112#note_1704981742 ### Plan #### Phase 1 ( %16.10) :point_left: Duo Chat GA requirement Enable cascading settings for banning AI features using the [cascading settings framework](https://docs.gitlab.com/ee/development/cascading_settings.html). This will involve an instance-wide setting and a group level setting (we already have a project-level setting) called `duo_features_enabled` that defaults to `true`. Customers can update these settings via the GraphQL API. Stretch goal for %16.10 is to make it possible to update these settings via the GitLab UI as well but that might bleed into %16.11 due to the shortened release cycle. How cascading settings work: 1. A new setting is added at both the application level and group level so that self-managed/dedicated GitLab instances can manage the setting for all groups at once and GitLab.com customers can manage the setting for their groups. 2. When a parent object changes the value of `duo_features_enabled`, all child objects (subgroups, projects) have the value of `duo_features_enabled` updated as well. This is the "cascade." 3. Group/project owners for child objects can change the value of `duo_features_enabled` so that it no longer matches the parent. As as result, a group could enable AI features but a specific project within that group could disable AI features. Or the other way around. 4. If the root group owner or instance admin chooses to "lock" `duo_features_enabled` (locking is part of the cascading settings framework), then all child objects will have the same value for `duo_features_enabled` as the parent. Locking can happen at any level (application level, root group level, subgroup level) 5. The default on all levels is `duo_features_enabled` = `true`. 6. If `duo_features_enabled` = `false` on instance/top-group/sub-group/project then data on that level will not be sent to AI. 1. This applies to AI usage in GitLab as well as in clients like IDEs and CLI. 2. This applies to Duo features that have matured to GA as well as experimental and beta AI features. 7. A user attempting to use Duo features with data residing in a level that has banned AI will be presented with a message that explains why the AI feature cannot be applied to the data. (It is acceptable if this slips %"16.11") Phase 1 is a must have requirement for releasing Duo Chat as GA. [See reasoning](https://gitlab.com/gitlab-org/gitlab/-/issues/440628#note_1766748999 "Implement New Toggle to control Chat in the time it is GA but not yet controlled by the add-on"). #### Phase 2 ( %16.11) Add override capability to cascading settings at the instance and root group level. The cascading settings framework allows admins to create secure defaults for AI settings and to enforce default values via the locking mechanism. But, it does not allow the following scenarios: - An instance admin or root group owner wants to ensure that AI features are off for all projects/groups except for a specific list of projects/groups. - An instance admin or root group owners wants to ensure that AI features are on for all projects/groups except for a specific list of projects/groups. Large enterprises want more granular control over AI features and as a result the limitations of cascading settings might not meet their needs. To meet their needs, we will add an override layer to the `duo_features_enabled` cascading settings. The override layer will only be controlled by an instance admin or root group owner. Using this setting, the admin/owner can add a specific list of groups/projects to an AI “allow list” or an AI “block list”. If a group/project is in the allow list, that takes precedences over the `duo_features_enabled` setting that is set via cascading settings. If a group/project is in the block list, that takes precedences over the `duo_features_enabled` setting that is set via cascading settings.