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 theproduct
content type with a custom fieldfield_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 likefield_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()
.”