Why teams add GLPI AI ticket summaries with OpenAI
Service desk teams often inherit tickets with long timelines: dozens of follow-ups, reassignments between groups, and internal notes that a new technician must read before they can act. The GLPI AI plugin summarizes ticket timelines by sending ticket content to OpenAI, so the work that matters before rollout is not the prompt or the summary itself. It is the OpenAI key and organization, the spend limits set on that account, the caching behavior inside GLPI, and a clear record of which ticket content leaves the instance. Teams usually adopt the plugin to shorten handoffs and onboarding for technicians, but the benefit only holds if the data path has been approved first.
Three roles typically make this decision together. The GLPI owner, often the platform or service desk lead, installs the plugin, maps the OpenAI settings in GLPI, and decides which entities and ticket types are in scope. A security reviewer checks what ticket fields may contain, such as personal data, credentials pasted by requesters, or customer information, and whether that content may be processed by an external provider under your contracts. A partner is useful when the team lacks time to test the plugin against its own ticket data or to document the configuration for audit. Confirm the plugin version and its supported GLPI version with the plugin publisher before planning, since the GLPI 11 and 12 upgrade path can affect plugin compatibility.
Do the review before the plugin reaches more than a pilot group. Ask for a written list of the OpenAI account settings you need, including who owns the organization, how keys are issued and rotated, and which spend limits can be enforced. Test with anonymized or sample tickets, then compare the summaries against the full timeline to judge accuracy. Decide how long summaries are cached, who can regenerate them, and whether technicians may paste summary text into customer-facing replies. Recording these answers now gives the security reviewer evidence and gives the GLPI owner a stable baseline for the wider rollout.
What the AI summary module does and what it depends on
A ticket summary is only as trustworthy as the chain behind it: the timeline it reads, the OpenAI account it calls, the limits that stop runaway spend, the cache that holds the result, the GLPI rights that decide who sees it, and the GLPI and plugin versions that keep it working. Each component below is a place where configuration, ownership and data handling need a decision before go-live.
Ticket timeline as model input
The summary is built from the ticket's followups, tasks, solutions and status changes, so the content of the timeline is what leaves the instance. Check which item types the plugin includes, whether private followups and internal tasks are read, and whether attachments or linked asset data are added to the prompt. Ask the plugin maintainer to document the exact fields sent. Long timelines may be truncated, so confirm how that is handled and what the reader sees when it happens.
OpenAI organization and API key
The plugin authenticates to OpenAI with an API key tied to an organization and, usually, a project. Decide which OpenAI organization owns the key, who can rotate it, and where it is stored so it does not appear in GLPI configuration exports or logs. Confirm the plugin's supported key types and how it selects a model. Your data processing terms with OpenAI should be reviewed by your privacy and legal team before any ticket content is sent.
Usage caps and cost control
Each summary is a paid API request, so volume grows with ticket activity and with how often technicians regenerate summaries. Confirm whether the plugin offers per-user, per-entity or global request limits, token limits per request, and a monthly ceiling you can set in the OpenAI project. Ask what happens when a cap is reached: whether summaries fail silently, queue, or fall back to a message. Cost estimates should come from your own ticket volume and OpenAI's current pricing, not from this page.
Cached summary storage
A cached summary is stored in the GLPI database and reused until the timeline changes, which limits repeat calls. Confirm what triggers regeneration, how long a cached summary persists, and whether it is deleted with the ticket. Note that the cache holds model output derived from ticket content, so it inherits the retention and backup rules of the database. Include it in your backup and purge procedures and in any anonymized copies you make for testing.
GLPI rights that decide visibility
A summary should only be visible to a user who can already read every item it was built from. Test this directly: a requester, a technician outside the ticket's entity, and a user with restricted profile rights should each see only what the underlying ticket shows them. Confirm whether the plugin checks rights when it displays a cached summary as well as when it generates one. Entity and profile design from your GLPI authentication setup is the control that enforces this.
GLPI and plugin version lifecycle
The plugin must match your GLPI release, and GLPI 11 suspends plugins after a new version is detected until they are reactivated following major updates. Check the plugin's release notes for compatibility with GLPI 11 and the GLPI 12 release line before planning an upgrade, and rehearse the update on a copy. Record which plugin version is in production, because an unsupported plugin can stop working or stop receiving security fixes while GLPI itself continues to update.
How a ticket timeline reaches OpenAI and comes back
The data that leaves your GLPI instance is decided by configuration, not by the summary button. When a technician asks for a summary, GLPI gathers the ticket timeline content that the plugin is allowed to read and sends it to OpenAI with the API key and organization identifier you configured. OpenAI returns generated text, and the plugin stores that result on the ticket so later readers do not need to call the API again. Before go-live, list each item the plugin reads: the ticket description, followups, tasks, solutions, validation records, linked assets and users, and attachments. For each one, decide whether it is included, and whether private followups and technician-only notes are included too, since those often hold the most sensitive detail.
Anything included in that request leaves your infrastructure and is processed under the terms of the OpenAI account your organization holds. Your data processing terms, retention settings and any regional or zero-retention options depend on that account and its plan, so involve whoever owns vendor contracts and privacy review before enabling the feature. Confirm in the plugin's documentation exactly which GLPI objects, fields and file types it transmits, whether it strips HTML, email headers or signatures, and whether it sends user identifiers. Then confirm in OpenAI's current documentation how that account retains and uses API inputs. Do not rely on a general description of the plugin for this answer.
Test the path with a ticket that contains representative but non-production content, then inspect what the API receives, for example through a network capture in a test environment or a proxy you control. Check that the stored summary is visible only to the profiles that may already read the ticket, because a summary can expose private content to a wider audience than the source ticket. Record the decisions in your data inventory so that a later change to the included fields, the key or the organization is reviewed as a change to what leaves the instance.
Configuration decisions before you enable summaries
This table compares the configuration choices you make before summaries reach users, with the situations where each option fits and the risk it carries. Read each row as a decision to record in writing, then confirm the exact settings your plugin version exposes before you set them.
| Decision | Options to weigh | Risk to manage | When the option fits |
|---|---|---|---|
| Eligible ticket content | All timeline entries, or only followups, solutions and public content | Private technician notes can carry credentials, personal data or internal findings that leave the instance | Limit eligibility to content your data classification allows to reach an external model provider |
| Who can request a summary | All requesters, assigned technicians only, or a named profile group | Requesters may see or trigger summaries of tickets they should not read in full | Restrict to technician profiles when tickets hold sensitive operational detail |
| OpenAI organization and project | One shared organization, or separate projects per business unit or environment | A shared project mixes usage, spend and access across unrelated teams and makes incidents harder to trace | Separate projects when entities have different data handling duties or budgets |
| API key storage and rotation | Key entered in plugin settings, or supplied from a secrets store your team already operates | Keys stored in the database are readable by anyone with database access, and rotation becomes a manual change | Use a managed secrets store where your team has rotation procedures and audit logs |
| Usage caps per entity or team | Global cap, per-entity cap, or no cap with monitoring only | Without caps, a single busy queue can drive unexpected cost and exhaust shared quota | Per-entity caps fit multi-entity instances with separate cost centers |
| Cache retention and invalidation | Short retention, longer retention, or refresh on each new timeline entry | Stale summaries can mislead a technician who reads them without the latest updates | Short retention with invalidation on new entries suits active tickets |
| Write summaries back to tickets | Store the summary as a ticket followup or keep it as a transient view | Written summaries become ticket content, may be notified to requesters and become part of retained records | Write back only when your retention and notification rules already cover the text |
| Confirm plugin options | Check the settings screen and documentation for your exact plugin version | Options and defaults change between plugin versions, so a planned choice may not exist | Confirm before writing the decision record and before the first production test |
Rollout sequence from pilot to production
This sequence moves the AI summary plugin from a compatibility check to a tested pilot group and then to the full service desk. Each step closes with a record you keep, so the team can show what was configured, what data leaves the instance and how to undo the change.
Confirm version compatibility before any change
Check the running GLPI version, PHP version and database version against the GLPI prerequisites. Confirm with the plugin publisher that the plugin release supports your target GLPI release, and note any plugin dependency. Record the pinned GLPI, PHP, database and plugin versions in a compatibility record that the platform owner signs off. Output: a signed compatibility record that names the exact versions used in every later step.
Back up database, files and config keys
Before touching the instance, take the backups the GLPI update documentation requires: the database, the application files and the config directory. Include
glpi.keyandglpicrypt.keyin the config backup and store them with the rest of the backup set, not in a separate informal location. Restore the set to a separate host to confirm it works. Output: a verified backup set with a restore test log.Create the OpenAI organization and dedicated key
In the OpenAI console, create or select the organization that will own GLPI traffic, then create one API key used only for this GLPI instance. Set a spend limit on the key or organization as the console allows today, and confirm the current options in OpenAI's own documentation because they change. Name a single owner and a rotation contact. Output: a key inventory entry that lists owner, purpose, spend limit and rotation contact, with the key value kept in your secret store and not in a ticket.
Configure the plugin and profile permissions
Install the plugin on a non-production copy of GLPI and enter the API key in the plugin configuration. Limit the summary action to the profiles that need it, such as technicians on specific entities, and keep requesters without access unless you decide otherwise. Set the usage caps and caching options the plugin exposes, and write down each value. Output: a tested configuration record and a profile-to-permission matrix that the service owner approves.
Test with sample tickets on a copy
Restore the backup to a non-production copy and run the summary feature on sample tickets, including long timelines, private followups, attachments and tickets that contain personal data. Compare each summary with the source timeline to judge accuracy and omissions. Confirm exactly which fields and notes are sent to the external service, and whether attachments are included. Output: a data-flow description and a sign-off from the security or privacy owner before any production use.
Verify caching and usage caps
Request a summary for the same ticket several times to confirm that repeated requests use the cache and do not send new calls, and that changes to the timeline are picked up as the plugin documents. Then lower a test cap and confirm that the plugin stops making calls once it is reached. Compare call counts in the GLPI logs with the usage shown in the OpenAI console. Output: a test log with pass or fail results and a written rollback procedure that disables the plugin and revokes the key.
Run a pilot with a limited user group
Enable the feature for one team or entity and a small set of technicians who agreed to report problems. Track spend, error rates, summary quality and any complaints about data exposure during the pilot. Note that GLPI 11.0 suspends plugins after a new version is detected and that they must be reactivated after major updates, so schedule a check of plugin status after each update. Output: a pilot report with a go or no-go decision from the service owner.
Roll out to production with a runbook
Expand access in stages, using the same profile matrix and caps verified in testing, and watch spend and errors after each stage. Publish a production runbook that covers key rotation, cap changes, the caching behavior you verified, and the rollback steps. Assign owners for monitoring and for any future GLPI or plugin update. Output: a production runbook and rollback procedure, both signed off, with the rollout stages recorded in the change log.
What drives the effort and cost of the AI summary setup
This table compares the main drivers of effort and cost for an AI ticket summary setup, showing whether each cost is one-time or recurring and what keeps it down. Use it to scope a quote, since the largest variables are entity count, ticket sensitivity and how often GLPI and plugin versions change. Expect most of the cost to sit in policy, testing and lifecycle work rather than in the initial plugin installation.
| Driver | Why it moves cost or effort | Type | How to keep it down |
|---|---|---|---|
| Entities and teams needing separate caps | Each entity or team that needs its own usage limit adds configuration, testing and reporting work | One-time setup, then recurring review | Start with one or two entities in the pilot and reuse a single cap pattern |
| Sensitivity of ticket content | Tickets with personal, health or financial data need data handling review and possibly exclusions before any text leaves the instance | One-time policy sign-off | Define which queues or categories are excluded before enabling summaries |
| GLPI version and plugin lifecycle | Each GLPI update suspends plugins until they are reactivated, and plugin compatibility must be rechecked | Recurring with each release | Plan updates on a fixed cycle and keep a dated test copy of the instance |
| Number of pilot users | More technicians means more feedback rounds, more prompt and summary quality checks, and more support questions | One-time pilot effort | Limit the pilot to a defined group with a written feedback form |
| Permission and caching tests | Summaries must respect GLPI profiles and entities, and cached output must not show to users who cannot read the source ticket | One-time testing, retested after changes | Test with accounts from each profile and entity before rollout |
| OpenAI usage | Charges follow model usage, which grows with ticket volume and timeline length; confirm current rates with OpenAI and your account owner | Recurring | Set usage caps, summarize only on request and cache results to avoid repeat calls |
| API key rotation and organization administration | Keys, organization membership and access to the OpenAI account need periodic rotation and documented ownership | Recurring | Store keys in a managed secrets store and document an owner and rotation schedule |
| Plugin updates and maintenance | Plugin releases and any compatibility fixes require testing against the GLPI version in use | Recurring | Ask the partner whether a maintenance retainer covers plugin updates |
How the summary module connects to GLPI and the rest of your stack
The summary module sits inside GLPI, so its access rules, data, secrets, backups and upgrades are inherited from the platform. Each card below names one connection and the check to make before enabling summaries on production tickets.
Profiles that gate summary requests
Summaries should be available only to the profiles that already handle the tickets involved. GLPI decides what a user can see through profiles and entities, so a summary request should never expose a ticket the requester could not open. Test with a requester profile, a technician in a child entity and a user outside the entity. Confirm whether the plugin checks ticket visibility on each request or only the menu entry.
Ticket and followup data sent for summarizing
A timeline summary draws on the ticket description, followups, tasks and solutions, and may include requester names and attached text. Decide which of these fields go into the prompt and whether private followups or task notes are included. Keep the field list in writing so security and privacy reviewers can compare it with your data classification. Confirm exactly which item types the plugin reads.
OpenAI key stored with other platform secrets
The OpenAI API key is a credential with spend and data access, so it belongs in the same secrets process as your database and mail passwords. Restrict who can read it, rotate it on staff changes and keep it out of ticket text, logs and exported configuration. Store the organization identifier alongside it so usage is attributable. Confirm where the plugin stores the key and whether it is encrypted at rest.
Backup and restore of database and config
Summaries are generated from ticket data, but any cached output lives in the GLPI database and the plugin configuration lives with the instance. The GLPI update documentation requires backing up the database, files and the config directory, including glpi.key and glpicrypt.key. A restore that lacks the key files can leave encrypted settings unreadable, so test a full restore on a copy before go-live. Confirm where cached summaries are stored and whether they are included in the database backup.
Plugin suspension during GLPI updates
Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. The summary module will therefore stop working until someone reactivates it, and the outage may go unnoticed if no one checks. Add a post-upgrade step that confirms the plugin is active and that a test ticket returns a summary. Confirm the plugin version that matches each GLPI release before scheduling the upgrade.
Usage monitoring and spend reporting
Each summary request is a paid call to an external service, so usage needs a limit and a report. Decide the monthly cap, who receives alerts when it is near, and whether usage is reviewed in your existing monitoring or in the OpenAI usage dashboard. Connect the usage check to the GLPI automatic actions your operations team already reviews. Confirm which usage caps the plugin enforces itself and which must be set in OpenAI.
Questions teams ask before setting up GLPI AI summaries
What does setting up GLPI AI summaries with OpenAI cost?
The cost has three parts: the implementation fee, OpenAI usage charges and any plugin licensing. DeployOpen does not publish prices. A quote follows from a written scope that names the GLPI instance, the ticket content in scope, the caps, the caching approach and the test plan. OpenAI bills API usage to your own account, so the recurring cost depends on how many timelines are summarized and how much text each request carries. Reducing the text sent and caching repeat summaries both lower that figure. Ask the quote to separate one-time work (installation, configuration, testing, documentation) from recurring work such as plugin updates, usage review and monitoring. Confirm with the plugin publisher whether any GLPI subscription applies to this plugin.
How long does a GLPI AI summary setup take to complete?
The schedule depends mostly on decisions made before installation: whether ticket content may leave your network, which timeline entries the summary reads, and how the OpenAI project and billing limits are approved. A single instance with one OpenAI project and a narrow set of ticket categories moves faster than one with several entities, separate data classes and a formal security review. Upgrades can add time. GLPI 11 suspends plugins after a new version is detected, and they must be reactivated after major updates, so confirm plugin compatibility with your target GLPI version first. DeployOpen does not publish durations for this work. The written scope sets the schedule, and it should include milestones for the test environment, the security review and the production rollout.
Who must the internal team provide before the setup starts?
Three roles matter. A GLPI administrator provides access to the instance, the plugin installation path, profiles and a set of test tickets, and confirms how summaries should appear to technicians and requesters. A security reviewer approves which ticket content may be sent to an external API, along with logging and retention expectations for prompts and responses. The OpenAI account owner creates or confirms the organization and project, sets billing limits, issues API keys with the narrowest permissions available and decides who can rotate them. Name a sponsor who signs off on the scope and a person who accepts the test results. Agreeing on these names before the first working session keeps decisions from waiting on access requests.
Can our own team set up the GLPI AI plugin alone?
Yes, a team with GLPI administration experience can install and configure the plugin itself, provided it can test in a non-production copy first. The work covers installing the plugin for your GLPI version, storing the OpenAI key where the plugin expects it, choosing which ticket content is sent, and documenting the result. The steps that most often need outside help are the review of data flows against your policies and the first production rollout without disrupting active ticket work. DeployOpen works on fixed-scope engagements agreed in writing and can also provide ongoing support as a retainer. Compare your staff time for testing, the review and each future plugin update against a written scope from a partner.
Does ticket data leave our GLPI instance when summaries run?
Yes. When a summary runs, the plugin sends the text it is configured to read from a ticket's timeline to the OpenAI API, so that content leaves your GLPI server and network boundary. Which fields and entries are included depends on the plugin configuration and any changes your team makes, so confirm the exact behavior for the version you install. Treat this as a transfer to a third party. Record the OpenAI terms that apply to your account, decide which data classes are allowed, and check whether your contracts or sector rules permit the transfer. If a ticket category falls outside those rules, keep summaries switched off for it.
How do we limit which ticket content is sent to OpenAI?
Limit the data at three points: the ticket fields and timeline entries the plugin reads, any text removed before the request is sent, and the entities or categories where summaries are enabled. Start with an allowlist of ticket categories and exclude tickets that carry health, payment or legal material. Confirm whether the plugin can strip names, email addresses or other identifiers before sending. If it cannot, the removal step belongs in your own review process or change set. The Anonymize plugin is designed to create safe test and training copies, so it does not clean live requests. Test with sample tickets that contain dummy identifiers, and inspect the outgoing payload in a test environment before enabling production.
How do we check that usage caps and caching actually work?
Check caps and caching in three places: the plugin configuration, the OpenAI project's usage and budget settings, and the GLPI logs. For caps, send a batch of test tickets above the configured limit and confirm that requests stop and that users see a clear message. For caching, summarize the same unchanged ticket twice and confirm from the logs or the OpenAI usage dashboard that the second request did not call the API. Then change the timeline and confirm the summary is regenerated. Repeat these checks after each plugin or GLPI update, because new versions can change defaults. Record the results in a runbook so the security reviewer and the OpenAI account owner see the same evidence.
Which GLPI versions and prerequisites must the AI plugin match?
The plugin must match your GLPI release, and GLPI's platform prerequisites apply first. The GLPI 11.0 installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and the GLPI README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later. Check the plugin's compatibility list before choosing the GLPI version. Confirm that the GLPI server can reach the OpenAI API through any proxy, and that outbound firewall rules and TLS inspection do not break the calls. Follow the backup procedure in the GLPI update docs before any upgrade, and confirm that plugins are reactivated after each major update.
How DeployOpen scopes and delivers the AI summary setup
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For GLPI AI ticket summaries with OpenAI, that means the OpenAI account, key handling, usage limits, caching and data flow are designed with your security and compliance team before the plugin is switched on for real tickets.
How we scope
- Written scope lists the GLPI instance, entities and ticket types that will receive summaries, agreed before work starts.
- Scope records which OpenAI organization, project and key ownership model your team has approved for the integration.
- Scope states the usage caps, caching rules and retention expectations that the summary feature must respect in your environment.
- Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before any configuration begins.
How we build
- Configure the GLPI AI plugin against a non-production instance first, using a restricted OpenAI key with spending limits set.
- Test summaries on representative ticket timelines, including tickets with attachments, private notes and personal data.
- Verify that the cache behaves as designed and that cached summaries are not shown to users outside their GLPI profile rights.
- Check plugin version compatibility with the GLPI release running in your infrastructure before promoting the change.
How we hand over
- Deliver a configuration record covering keys, organization settings, usage caps, cache duration and enabled entities.
- Document the data flow, showing which ticket content leaves the instance, which provider receives it and what is logged.
- Provide a runbook for rotating the OpenAI key, reviewing usage and disabling the feature quickly if needed.
- Walk your operations and security staff through the test results so they can repeat the checks after changes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering plugin and GLPI updates.
- Retainer work can include rechecking usage caps, provider settings and data flow when your OpenAI account or policy changes.
- Ask any provider about data retention, training use and regional processing terms in writing, and confirm them with your legal team.
