AI Usage Guidelines

AI Usage Guidelines

Objective

This document establishes the guidelines for the responsible and ethical use of third-party Artificial Intelligence (AI) tools within Axelerant.

If you are interested on how we use AI at Axelerant read https://axelerant.atlassian.net/wiki/spaces/OA/pages/5252907093

Data Protection

Client Data Usage

  • Regional Preferences: Acknowledge and respect clients’ preferences regarding AI service providers, especially those from regions with stricter data protection laws (e.g., EU clients that are GDPR compliant).

  • Provider Trustworthiness: Be aware that clients may have distrust towards certain AI providers or may prohibit the use of AI tools entirely.

Subscription and Data Privacy

  • Authorized Subscriptions Only: Use only company-approved, paid subscriptions for AI tools. Do not use free or personal accounts for work.

  • Provider Data Policies: Be aware that even if AI providers state that data will not be used for training, we need to do our due diligence to make sure any sensitive data is sanitised before sharing.

Client Empathy and Transparency

Ensure empathy and transparency in all communications regarding AI usage. Understand and acknowledge client concerns and demonstrate Axelerant’s commitment to ethical and responsible AI practices.

Human in the loop

We will keep human in the loop and AI only augments human capability and not replace entirely. Align with your team on the human checkpoints that we have for each use case where we use AI.

Acceptable Usage Guidelines

Permitted Use Cases

  • General Queries: It is permissible to use AI tools for generic questions unrelated to client-specific data. Examples include technical how-to queries or coding concepts.

  • No Client Information: Do not share client code, proprietary data, or any identifiable client information.

Restrictions When Client Withholds Permission

If a client denies permission for AI usage:

  • Do not use AI tools to process, analyze, or assist with the codebase.

  • Do not submit queries containing client-specific information.

Generic Guidelines

Reformulate queries to be generic and anonymized without exposing client context.

  • Below are some examples

What Not to Do (Client-Specific Query)

“We’re working for Acme Corp on a Drupal 10 multisite setup. Their site breaks when using hook_entity_presave() on the product content type with a custom field field_acme_sku. Can you help?”

How to Reformulate (Generic Version)

“In Drupal 10, how do I implement hook_entity_presave() to modify a custom field value before saving, particularly for a content type with a field like field_custom_sku in a multisite setup?”


What Not to Do (Code With Identifiers)

function acme_product_presave(EntityInterface $entity) { $sku = $entity->get('field_acme_sku')->value; // custom logic here }

How to Reformulate (Generic Code)

function custom_entity_presave(EntityInterface $entity) { if ($entity->bundle() === 'product') { $sku = $entity->get('field_custom_sku')->value; // generalized logic here } }

If changing the code as above takes considerable amount of time, consider divide and conquer approach were you divide the problem into multiple smaller issues and instead of sharing the code share the context to get potential solutions (like in example above and below).


What Not to Do (Client-Specific Business Logic)

“We have a client in the healthcare industry that needs to restrict access to a custom patient node type using role-based access for doctors and admins. We're using node_access() and it’s not working.”

How to Reformulate (Generic Version)

“In Drupal 10, how can I implement role-based access control for a custom content type so that only users with specific roles (e.g., 'manager', 'editor') can view or edit the content? I’m using hook_node_access().”