Merge pull request #2635 from sdgilley/sdg-release-foundry-toc

DIRTY PR - pull main into release-foundry-toc

Author: rmca14

articles/ai-foundry/model-inference/concepts/models.md

@@ -17,6 +17,9 @@ ms.custom: references_regions, tool_generated
 
 Azure AI model inference in Azure AI Foundry gives you access to flagship models in Azure AI to consume them as APIs without hosting them on your infrastructure.
 
+> [!TIP]
+> DeepSeek-R1 is available for deployment as [Serverless API endpoint](../../../ai-studio/how-to/deploy-models-deepseek.md).
+
 :::image type="content" source="../media/models/models-catalog.gif" alt-text="An animation showing Azure AI studio model catalog section and the models available." lightbox="../media/models/models-catalog.gif":::
 
 Model availability varies by model provider, deployment SKU, and cloud. All models available in Azure AI Model Inference support the [Global standard](deployment-types.md#global-standard) deployment type which uses global capacity to guarantee throughput. [Azure OpenAI models](#azure-openai) also support regional deployments and [sovereign clouds](/entra/identity-platform/authentication-national-cloud)—Azure Government, Azure Germany, and Azure China 21Vianet.

articles/ai-foundry/model-inference/how-to/quickstart-ai-project.md

@@ -141,7 +141,7 @@ Use the parameter `model="<deployment-name>` to route your request to this deplo
 
 ## Move from Serverless API Endpoints to Azure AI model inference
 
-Although you configured the project to use the Azure AI model inference, existing model deployments continue to exit within the project as Serverless API Endpoints. Those deployments aren't moved for you. Hence, you can progressively upgrade any existing code that reference previous model deployments. To start moving the model deployments, we recommend the following workflow:
+Although you configured the project to use the Azure AI model inference, existing model deployments continue to exist within the project as Serverless API Endpoints. Those deployments aren't moved for you. Hence, you can progressively upgrade any existing code that reference previous model deployments. To start moving the model deployments, we recommend the following workflow:
 
 1. Recreate the model deployment in Azure AI model inference. This model deployment is accessible under the **Azure AI model inference endpoint**.
 

articles/ai-foundry/model-inference/overview.md

@@ -18,6 +18,9 @@ recommendations: false
 
 Azure AI model inference provides access to the most powerful models available in the Azure AI model catalog. The models come from key model providers in the industry, including OpenAI, Microsoft, Meta, Mistral, Cohere, G42, and AI21 Labs. These models can be integrated with software solutions to deliver a wide range of tasks that include content generation, summarization, image understanding, semantic search, and code generation.
 
+> [!TIP]
+> DeepSeek-R1 is available for deployment as [Serverless API endpoint](../../ai-studio/how-to/deploy-models-deepseek.md).
+
 Azure AI model inference provides a way to **consume models as APIs without hosting them on your infrastructure**. Models are hosted in a Microsoft-managed infrastructure, which enables API-based access to the model provider's model. API-based access can dramatically reduce the cost of accessing a model and simplify the provisioning experience.
 
 Azure AI model inference is part of Azure AI Services, and users can access the service through [REST APIs](./reference/reference-model-inference-api.md), [SDKs in several languages](supported-languages.md) such as Python, C#, JavaScript, and Java. You can also use the Azure AI model inference from [Azure AI Foundry by configuring a connection](how-to/configure-project-connection.md).

articles/ai-services/agents/concepts/model-region-support.md

@@ -7,7 +7,7 @@ author: aahill
 ms.author: aahi
 ms.service: azure-ai-agent-service
 ms.topic: conceptual
-ms.date: 01/07/2025
+ms.date: 01/29/2025
 ms.custom: azure-ai-agents
 ---
 
@@ -27,6 +27,7 @@ Azure AI Agent Service supports the same models as the chat completions API in A
 | francecentral | -                          | -                          | -                               | ✅                  | ✅                           | -                           | -                               | ✅ | ✅                         | ✅                          | -                          | ✅                             |
 | japaneast     | -                          | -                          | -                               | -                   | -                           | -                           | -                               | -                      | ✅                         | -                          | ✅                         | ✅                              |
 | norwayeast    |-  |  - |  - | -  | ✅ | -  |-  | -  | -  | -  | -  | - |
+| southindia    | - | - | - | - | ✅ | - | - | - | - | ✅ | ✅ | - |
 | swedencentral    | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ | ✅ | - | ✅ |
 | uksouth       | -                          | -                          | -                               | -                   | ✅                          | ✅                           | -                               | -                       | ✅                          | ✅                         | ✅                          | ✅                             |
 | westus        | ✅                         | ✅                          | ✅                            | -                   | ✅                          | -                           | ✅                               | - | -                          | ✅                         | ✅                          | -                              |
@@ -37,9 +38,10 @@ Azure AI Agent Service supports the same models as the chat completions API in A
 
 The Azure AI Agent Service also supports the following models from the Azure AI Foundry model catalog.
 
-* Llama 3.1-70B-instruct
+* Meta-Llama-405B-Instruct
 * Mistral-large-2407
-* Cohere command R+
+* Cohere-command-r-plus
+* Cohere-command-r
 
 To use these models, you can use Azure AI Foundry portal to make a deployment, and then reference it in your agent. 
 

articles/ai-services/computer-vision/concept-liveness-abuse-monitoring.md

@@ -9,7 +9,7 @@ manager: nitinme
 ms.service: azure-ai-vision
 ms.subservice: azure-ai-face
 ms.topic: conceptual
-ms.date: 11/05/2023
+ms.date: 01/29/2025
 ms.author: pafarley
 ms.custom:
   - ignite-2023
@@ -20,21 +20,21 @@ feedback_help_link_url: https://learn.microsoft.com/answers/tags/156/azure-face
 
 Azure AI Face liveness detection lets you detect and mitigate instances of recurring content and/or behaviors that indicate a violation of the [Code of Conduct](/legal/cognitive-services/face/code-of-conduct?context=/azure/ai-services/computer-vision/context/context) or other applicable product terms. This guide shows you how to work with these features to ensure your application is compliant with Azure policy.
 
-Details on how data is handled can be found on the [Data, Privacy and Security](/legal/cognitive-services/openai/data-privacy?context=/azure/ai-services/openai/context/context) page.
+Details on how data is handled can be found on the [Data, Privacy, and Security](/legal/cognitive-services/openai/data-privacy?context=/azure/ai-services/openai/context/context) page.
 
 [!INCLUDE [liveness-sdk-gate](./includes/liveness-sdk-gate.md)]
 
 ## Components of abuse monitoring
 
 There are several components to Face liveness abuse monitoring:
-- **Session management**: Your backend application system creates liveness detection sessions on behalf of your end-users. The Face service issues authorization tokens for a particular session, and each is valid for a limited number of API calls. When the end-user encounters a failure during liveness detection, a new token is requested. This allows the backend application to assess the risk of allowing additional liveness retries. An excessive number of retries may indicate a brute force adversarial attempt to bypass the liveness detection system.
+- **Session management**: Your backend application system creates liveness detection sessions on behalf of your end-users. The Face service issues authorization tokens for a particular session, and each is valid for a limited number of API calls. When the end-user encounters a failure during liveness detection, a new token is requested. This allows the backend application to assess the risk of allowing more liveness retries. An excessive number of retries may indicate a brute force adversarial attempt to bypass the liveness detection system.
 - **Temporary correlation identifier**: The session creation process prompts you to assign a temporary 128-bit correlation GUID (globally unique identifier) for each end-user of your application system. This lets you associate each session with an individual. Classifier models on the service backend can detect presentation attack cues and observe failure patterns across the usage of a particular GUID. This GUID must be resettable on demand to support the manual override of the automated abuse mitigation system.
 - **Abuse pattern capture**: Azure AI Face liveness detection service looks at customer usage patterns and employs algorithms and heuristics to detect indicators of potential abuse. Detected patterns consider, for example, the frequency and severity at which presentation attack content is detected in a customer's image capture.
 - **Human review and decision**: When the correlation identifiers are flagged through abuse pattern capture as described above, no further sessions can be created for those identifiers. You should allow authorized employees to assess the traffic patterns and either confirm or override the determination based on predefined guidelines and policies. If human review concludes that an override is needed, you should generate a new temporary correlation GUID for the individual in order to generate more sessions.
 - **Notification and action**: When a threshold of abusive behavior has been confirmed based on the preceding steps, the customer should be informed of the determination by email. Except in cases of severe or recurring abuse, customers typically are given an opportunity to explain or remediate—and implement mechanisms to prevent the recurrence of—the abusive behavior. Failure to address the behavior, or recurring or severe abuse, may result in the suspension or termination of your Limited Access eligibility for Azure AI Face resources and/or capabilities.
 
-## Next steps
+## Related content
 
 - [Learn more about understanding and mitigating risks associated with identity management](/azure/security/fundamentals/identity-management-overview)
-- [Learn more about how data is processed in connection with abuse monitoring](/legal/cognitive-services/face/data-privacy-security?context=%2Fazure%2Fai-services%2Fcomputer-vision%2Fcontext%2Fcontext)
+- [Learn more about how data is processed for abuse monitoring](/legal/cognitive-services/face/data-privacy-security?context=%2Fazure%2Fai-services%2Fcomputer-vision%2Fcontext%2Fcontext)
 - [Learn more about supporting human judgment in your application system](/legal/cognitive-services/face/characteristics-and-limitations?context=%2Fazure%2Fai-services%2Fcomputer-vision%2Fcontext%2Fcontext#design-the-system-to-support-human-judgment)

articles/ai-services/computer-vision/enrollment-overview.md

@@ -7,26 +7,26 @@ manager: nitinme
 
 ms.service: azure-ai-vision
 ms.subservice: azure-ai-face
-ms.topic: best-practice
-ms.date: 02/14/2024
+ms.topic: conceptual
+ms.date: 01/29/2025
 ms.author: pafarley
 feedback_help_link_url: https://learn.microsoft.com/answers/tags/156/azure-face
 ---
 
 # Best practices for adding users to a Face service
 
-In order to use the Azure AI Face API for face verification or identification, you need to enroll faces into a **LargePersonGroup** or similar [data structure](/azure/ai-services/computer-vision/concept-face-recognition-data-structures). This deep-dive demonstrates best practices for gathering meaningful consent from users and example logic to create high-quality enrollments that will optimize recognition accuracy. 
+In order to use the Azure AI Face API for face verification or identification, you need to enroll faces into a **LargePersonGroup** or similar [data structure](/azure/ai-services/computer-vision/concept-face-recognition-data-structures). This deep-dive demonstrates best practices for gathering meaningful consent from users and example logic to create high-quality enrollments that optimize recognition accuracy. 
 
 ## Meaningful consent 
 
 One of the key purposes of an enrollment application for facial recognition is to give users the opportunity to consent to the use of images of their face for specific purposes, such as access to a worksite. Because facial recognition technologies may be perceived as collecting sensitive personal data, it's especially important to ask for consent in a way that is both transparent and respectful. Consent is meaningful to users when it empowers them to make the decision that they feel is best for them.   
 
 Based on Microsoft user research, Microsoft's Responsible AI principles, and [external research](ftp://ftp.cs.washington.edu/tr/2000/12/UW-CSE-00-12-02.pdf), we have found that consent is meaningful when it offers the following to users enrolling in the technology:
 
-* Awareness: Users should have no doubt when they are being asked to provide their face template or enrollment photos. 
-* Understanding: Users should be able to accurately describe in their own words what they were being asked for, by whom, to what end, and with what assurances. 
-* Freedom of choice: Users should not feel coerced or manipulated when choosing whether to consent and enroll in facial recognition. 
-* Control: Users should be able to revoke their consent and delete their data at any time. 
+* **Awareness**: Users should have no doubt when they're being asked to provide their face template or enrollment photos. 
+* **Understanding**: Users should be able to accurately describe in their own words what they were being asked for, by whom, to what end, and with what assurances. 
+* **Freedom of choice**: Users shouldn't feel coerced or manipulated when choosing whether to consent and enroll in facial recognition. 
+* **Control**: Users should be able to revoke their consent and delete their data at any time. 
 
 This section offers guidance for developing an enrollment application for facial recognition. This guidance has been developed based on Microsoft user research in the context of enrolling individuals in facial recognition for building entry. Therefore, these recommendations might not apply to all facial recognition solutions. Responsible use for Face API depends strongly on the specific context in which it's integrated, so the prioritization and application of these recommendations should be adapted to your scenario. 
 
@@ -40,11 +40,14 @@ Before you design an enrollment flow, think about how the application you're bui
 |Category | Recommendations |
 |---|---|
 |Hardware | Consider the camera quality of the enrollment device. |
-|Recommended enrollment features | Include a log-on step with multifactor authentication. </br></br>Link user information like an alias or identification number with their face template ID from the Face API (known as person ID). This mapping is necessary to retrieve and manage a user's enrollment. Note: person ID should be treated as a secret in the application.</br></br>Set up an automated process to delete all enrollment data, including the face templates and enrollment photos of people who are no longer users of facial recognition technology, such as former employees. </br></br>Avoid auto-enrollment, as it does not give the user the awareness, understanding, freedom of choice, or control that is recommended for obtaining consent. </br></br>Ask users for permission to save the images used for enrollment. This is useful when there is a model update since new enrollment photos will be required to re-enroll in the new model about every 10 months. If the original images aren't saved, users will need to go through the enrollment process from the beginning.</br></br>Allow users to opt out of storing photos in the system. To make the choice clearer, you can add a second consent request screen for saving the enrollment photos. </br></br>If photos are saved, create an automated process to re-enroll all users when there is a model update. Users who saved their enrollment photos will not have to enroll themselves again. </br></br>Create an app feature that allows designated administrators to override certain quality filters if a user has trouble enrolling. |
+|Recommended enrollment features | Include a sign-in step with multifactor authentication. </br></br>Link user information like an alias or identification number with their face template ID from the Face API (known as person ID). This mapping is necessary to retrieve and manage a user's enrollment. Note: person ID should be treated as a secret in the application.</br></br>Set up an automated process to delete all enrollment data, including the face templates and enrollment photos of people who are no longer users of facial recognition technology, such as former employees. </br></br>Avoid auto-enrollment, as it does not give the user the awareness, understanding, freedom of choice, or control that is recommended for obtaining consent. </br></br>Ask users for permission to save the images used for enrollment. This is useful when there is a model update since new enrollment photos will be required to re-enroll in the new model about every 10 months. If the original images aren't saved, users need to go through the enrollment process from the beginning. </br></br>Allow users to opt out of storing photos in the system. To make the choice clearer, you can add a second consent request screen for saving the enrollment photos. </br></br>If photos are saved, create an automated process to re-enroll all users when there is a model update. Users who saved their enrollment photos won't have to enroll themselves again. </br></br>Create an app feature that allows designated administrators to override certain quality filters if a user has trouble enrolling. |
 |Security | Azure AI services follow [best practices](../cognitive-services-virtual-networks.md?tabs=portal) for encrypting user data at rest and in transit. The following are other practices that can help uphold the security promises you make to users during the enrollment experience. </br></br>Take security measures to ensure that no one has access to the person ID at any point during enrollment. Note: PersonID should be treated as a secret in the enrollment system. </br></br>Use [role-based access control](/azure/role-based-access-control/overview) with Azure AI services. </br></br>Use token-based authentication and/or shared access signatures (SAS) over keys and secrets to access resources like databases. By using request or SAS tokens, you can grant limited access to data without compromising your account keys, and you can specify an expiry time on the token. </br></br>Never store any secrets, keys, or passwords in your app. |
 |User privacy |Provide a range of enrollment options to address different levels of privacy concerns. Do not mandate that people use their personal devices to enroll into a facial recognition system. </br></br>Allow users to re-enroll, revoke consent, and delete data from the enrollment application at any time and for any reason. |
 |Accessibility |Follow accessibility standards (for example, [ADA](https://www.ada.gov/regs2010/2010ADAStandards/2010ADAstandards.htm) or [W3C](https://www.w3.org/TR/WCAG21/)) to ensure the application is usable by people with mobility or visual impairments. |
 
-## Next steps  
+## Next step
 
-Follow the [Build an enrollment app](Tutorials/build-enrollment-app.md) guide to get started with a sample enrollment app. Then customize it or write your own app to suit the needs of your product.
+Follow the Build enrollment app guide to get started with a sample enrollment app. Then customize it or write your own app to suit the needs of your product.
+
+[!div class="nextstepaction"]
+[Build an enrollment app](Tutorials/build-enrollment-app.md)