Create new AI case form
Use the Create New AI case form in the AI Control Tower to report an AI case with the necessary details.
See the following table for a description of the field values.
| Field | Description |
|---|---|
| Number | Number of the request. This field is automatically set to a request number. |
| Name | Name of the AI case. For example, `Incorrect AI recommendation`. |
| Description | Description about the AI case in detail. For example, include information such as the expected recommendation, actual suggestion, context, impact, and steps to reproduce the issue, especially for cases such as Incorrect AI Recommendation. |
| Type | Type of the AI case. This field is automatically set to AI case. |
| Sub-type | Subtype of the case. For example, Adversarial attacks \(Deliberate manipulation of AI models to produce incorrect results\). |
| State | Workflow state of the request. This field is automatically set to New. |
| Priority | Urgency of the AI case. It enables the AI case team to triage requests effectively and responds based on how critical the request is. The options are as follows:- Critical - High - Moderate - Low - Planning |
| Requester | Name of the person who raised the request. |
| Requested on behalf of | Name of the person that you created the request for. |
| Primary entity | Entity impacted by the AI case. Only the entities identified in the impacted areas are available for selection as the primary entity. |
| Entity owner | User who is the owner of the entity. This field is automatically set based on the entity selected in the Impacted areas related list. |
| Assignment | |
| Assignment group | Group that is assigned to the request.Note: The assignment group is preconfigured to the request type during the configuration setup. |
| Case analyst | Analyst who will analyze and work on the AI case. The AI case analyst is a part of the Assignment group. |
| Watch list | Person who must be informed about the AI case. |
| Accountable executive | Person who is accountable for the AI case. |
| Primary origin | |
| Location | Location where the AI case occurred. For example, Japan. |
| Sub-location | Sub location of the AI case occurrence. For example, the sub location is Tokyo. |
| Impacted business unit | Business unit that is affected by the reported AI case. For example, Finance. |
| Impacted department | Department that is affected by the AI case. For example, Customer support. |
| Source | Source of the AI case creation. This field is automatically set to Manual when the case is manually created. If the case is reported from the Employee Center, the field displays the source as Employee Center. |
| Additional source | Mode of how the AI case is reported when the case is created manually. This field is available only when Manual is selected from the Source field and the record is saved. The choices are as follows:- Email - Phone |
| Schedule | |
| Date of occurrence | Date when the AI case occurred. For example, the case may have occurred on 18-02-2025. |
| Date of discovery | Date when the case was discovered. For example, the case may have occurred on 18-02-2025, but was discovered on 12-03-2025. |
| Reported date | Date the case is reported. |
| Case closure SLA | Expected date of case closure. |
| Investigation planned start | Planned start date to investigate the case. |
| Investigation actual start | Actual start date of case investigation. |
| Remediation planned start | Planned start date to remediate the case. |
| Remediation actual start | Actual start date of case remediation. |
| Investigation planned end | Planned end date to investigate the case. |
| Investigation actual end | Actual end date of case investigation. |
| Remediation planned end | Planned end date of case remediation. |
| Remediation actual end | Actual end date of case remediation. |
| Breach analysis | |
| Breach status | Status to indicate if a breach has occurred or not. The choices are as follows:- To be determined: This value is the default value. - Breach detected: If the breach is confirmed. - Future potential: If the breach hasn’t occurred but may occur in the future. - Not a breach: When there’s no breach detected. |
| Breach start | Date the breach started. This field only appears when Breach detected or Future potential is selected from the Breach status field. |
| Reporting status | Status of the AI case being reported to the regulators. This field is automatically set based on the reporting status of the regulations associated with the case. If an AI case has many regulations and even if one regulation is identified as reportable, then the reporting status of the case is set to Reportable. The default value of this field is To be determined. |
| Breach end | Date the breach ended. This field only appears when Breach detected or Future potential is selected from the Breach status field. |
| Breach significance identified | Date when the user identifies that the breach is significant. This field only appears when Breach detected or Future potential is selected from the Breach status field. |
| Root cause analysis | |
| Primary cause | Primary cause of the AI case occurrence. This field is automatically set to the primary cause that is selected in the Cause and consequences related list. |
| Primary consequence | Consequences of the primary cause for the AI case. |
| Overall observations | Observations made regarding the AI case. |
| Remediation taken | Field to indicate if remediation measures have been taken to address the AI case. The choices are as follows:- Yes - No |
| Overall preventive measures | Preventive measures taken toward the case. |
| Activity | |
| Work notes \(Private\) | Notes or information about the request. |
| Additional comments \(Customer visible\) | Additional information about the request that you want to share with your customers. |