Home •Blog
TTMS Blog
TTMS experts about the IT world, the latest technologies and the solutions we implement.
Sort by topics
Search results for the term: “chatGPT”
Practical Applications of Using ChatGPT for Business
In a digital era, where efficiency and immediacy are treasured values, businesses continuously seek innovative solutions to enhance their operations. Artificial Intelligence (AI), specifically Conversational AI, has emerged as the knight in shining armor.
Read
How AI can revolutionize customer service: ChatGPT for customer service
Artificial intelligence (AI) is revolutionizing customer service. Learn how ChatGPT improves speed, personalization and efficiency, benefiting businesses and customers.
Read
ChatGPT 4o as a content creation tool – chatgpt 4 vs 4o – what is the difference?
What are we complaining about in 2024? Let’s list: lack of time, weather anomalies, rising food prices, perpetually lost AirPods, the plethora of streaming services, the intellectual deficiencies of Chat GPT… And let’s stop here. Yes, you read that right – in recent months, there has been a lot of grumbling about the low substantive […]
Read
Will AI Replace Software Testers? How AI Is Changing QA
At another session in the TTMS Tech Talks series, we explored how artificial intelligence is changing the work of software testers. On October 20, 2026, Małgorzata Struzik, QA Engineer at TTMS, presented “Will AI Take Testers’ Jobs? Facts, Myths, and the Future of QA.” Małgorzata explored the tasks where AI can support testers and shared her experience of trying out one of the tools herself. Her presentation opened a discussion about the future of the profession, collaboration between testers and developers, and the skills needed to use AI in IT projects. Tech Talks – sharing knowledge at TTMS Tech Talks is a series of short internal sessions where TTMS employees share technical knowledge, project experience, and tools that help with everyday work. Each presentation ends with a Q&A session, creating space for discussion and the exchange of ideas. This helps us learn from one another and discover solutions used by other teams. 1. How does AI support testers’ everyday work? What does a software tester actually do? If you picture someone clicking buttons and checking whether an application works, you are seeing only part of the job. Before a quality assurance (QA) team begins testing, it needs to understand how the system should work, who will use it, and what consequences a defect could have. A tester decides what to check and how, looks for ambiguities in the requirements, and anticipates situations that could cause difficulties for users. When testers find a problem, they describe it so that a developer can reproduce it and identify its cause. Where can AI help with this work? It can suggest test cases: descriptions of what to check, which actions to perform, and what the expected outcome should be. It can also help write an automated test, analyze logs that record system events, or prepare test data. This support helps testers prepare the materials they need more quickly. Let’s take a closer look at suggested test cases. AI can quickly produce an organized set, with steps and an expected outcome for each case. It is easy to assume that the set is ready to use. However, a tester familiar with the application may notice that the company follows a different process or that a check for invalid input is missing. The tester then returns to the requirements, resolves the uncertainties, and revises AI’s suggestions. Our guide to AI in test automation explores how AI can support test creation, execution, and maintenance in greater detail. Tasks that take up a significant amount of the team’s time and produce results that can be reliably checked are a good starting point. 2. From requirements to test cases – AI in practice For the session, Małgorzata tried the process herself. She asked ChatGPT to prepare a detailed requirement describing how someone would use a website, then entered that description into the AI generator within a test management tool. She selected the tool from our list of the 10 best AI tools for testers. The tool quickly prepared the test cases. Małgorzata could read the suggestions as they were generated, and once saved, they formed an organized set. Each case was labeled as AI-generated. How did she assess the result? During the discussion, she explained that each suggested test still needs to be checked against the requirements: “A person will have to review each test case individually and check whether it matches the requirements, and that takes time too.” Małgorzata noted that this was a brief trial and that the requirements had not been developed in detail. Their description was created with ChatGPT’s help. In a real project, the first step would therefore be to check whether it reflects what the business and its users need from the application. If an important rule is missing, the generated tests may omit it too. They would then match the description while leaving some necessary checks uncovered. Małgorzata’s point about reviewing every suggestion raises a question: how much time can this approach save? To assess that, the team needs to account for preparing the description, generating the test cases, reading them, and making corrections. The total time can then be compared with the time needed to prepare a similar set without AI assistance. Time savings occur when the entire process takes less time and the resulting tests verify the requirements just as effectively. 3. Why can a passing test create a false sense of security? Automated tests created with AI assistance also need to be reviewed. Can an application pass all of them and still behave incorrectly? Małgorzata highlighted that possibility. If a test treats incorrect application behavior as correct, it will pass even though the feature is not working properly. A test suite may also leave out an important feature or business rule. The bread in the illustration presents a similar situation: it has a golden crust and a properly baked interior, so those checks would pass. However, it was supposed to be gluten-free, and wheat flour was used to make it. Checking its appearance and how well it was baked was not enough to confirm that it met the basic requirement. In software, a similar problem could involve a financial report that should be available only to authorized employees. AI prepares a test: the user clicks a button, and the report opens. The test passes. Everything looks fine until someone asks: what happens if an employee without permission clicks the same button? If nobody has checked that, it remains unclear whether the application properly protects access to the report. That is why a tester reviewing AI’s suggestions returns to the requirements and checks: whether each requirement has a corresponding test; whether the tests correctly describe how the application should behave; whether invalid data, missing permissions, and exceptional situations have been considered; whether testing covers the features whose failure would have the greatest impact on users and the business. Understanding how users work helps identify these gaps. A tester who knows who uses the report and what its data is used for can ask further questions and expand the test suite. This helps ensure that tests also cover what matters in everyday use of the application. 4. How might AI change the division of work between testers and developers? How might using AI affect the way a team divides its work? One participant suggested imagining two people, each able to both write code and test it. For one task, the first person implements a change while the second checks how it works. For the next, they switch roles, using AI for support. This approach would require learning on both sides. Testers would develop programming skills, while developers would gain a deeper understanding of testing techniques. A second person’s perspective would remain important for spotting defects or questioning the author’s assumptions. Whether this model would work would depend on the project, the team’s experience, and its software verification practices. Another idea emerged during the discussion: the team first prepares tests describing how the application should behave, and AI then generates code based on those tests. This puts the focus on the precision of the tests. If an important rule is missing, the generated software could pass every check and still fail to meet users’ needs. Both scenarios show why it helps for IT team members to understand one another’s responsibilities. Understanding code helps testers identify the cause of a defect, while knowledge of testing helps developers anticipate problems as they write a feature. We explore these changes further in our article on how AI is changing the work of developers, testers, and analysts in 2026. 5. How can you prepare a QA team to work with AI? Where should learning to work with AI begin? Toward the end of the session, participants expressed a need for practical training. They wanted to see how to use the tools, write prompts, and check the responses. They also suggested separate sessions on working with AI chat tools and using AI for programming, so that everyone could explore examples relevant to their responsibilities. Such training could focus on one specific task, such as preparing test cases together for a selected application feature. The team starts with an agreed requirement, provides it to AI, and then discusses the suggestions. This makes it possible to see what the tool included, what it missed, and how much work is needed to bring the tests to an acceptable standard. A task like this also provides an opportunity to establish a few ground rules: Which tools can we use? Employees should know which solutions have been approved for use in the project. What data can we share with them? Requirements, code, and documentation may contain confidential information. How that information is used must comply with company and client policies. Who reviews the output? Someone needs to assess the generated materials and decide whether they are suitable for further use. What do we check before approval? The team should agree on criteria such as alignment with requirements, correct expected outcomes, and coverage of important exceptional situations. The discussion also raised the question of responsibility for code created with AI assistance. Participants explained that, in their projects, the person approving a change is responsible for checking it, regardless of how it was created. Learning to use AI should therefore also include evaluating and correcting its suggestions. What does this mean for the future of testers? The session explored several scenarios, each prompting a discussion about the need to develop skills. AI can help prepare tests or analyze code. Using those outputs requires people who understand the application, can identify gaps, and know what further questions to ask. Małgorzata had already addressed this need to keep learning during the discussion about the profession’s future: “So we really need to be open to learning.” To learn more about using AI in software testing, explore QATANA – TTMS’s AI-supported software test management tool. Our team can discuss how this solution could be used in your project. FAQ What is the difference between quality assurance and software testing? Quality assurance (QA) covers the practices a team uses to prevent quality problems throughout software development. Software testing focuses on evaluating the product and identifying defects. QA can include reviewing requirements, agreeing on development standards, and improving how changes are checked before release. Testing provides evidence about how the software behaves under specific conditions. For a business, both matter: preventing misunderstandings early can reduce rework, while testing helps identify problems in the implemented solution. What is the difference between a test scenario and a test case? A test scenario describes a situation or activity that needs to be checked, such as a customer completing an online purchase. A test case gives more detailed instructions, including the starting conditions, input data, actions, and expected results. One scenario can require several test cases to cover different outcomes. For example, purchasing a product may involve a successful payment, a declined transaction, or an interruption during checkout. Teams should agree on these terms because naming conventions can differ between projects and tools. Can AI help with testing older software that has incomplete documentation? AI can help organize available information and suggest questions or initial test cases based on existing materials. These might include user guides, historical defect reports, support tickets, and existing tests. The main difficulty is establishing which behavior is actually correct. Older software may contain workarounds or defects that users have come to accept, and describing its current behavior can accidentally turn those problems into requirements. Business users and product owners should therefore help confirm the expected behavior. A useful starting point is one well-understood process whose rules can be checked before expanding the scope. What are flaky tests, and why do they matter when evaluating AI-generated tests? Flaky tests produce inconsistent results even when the software being tested has not changed. They can be affected by timing, shared test data, unstable environments, or dependencies on external services. Such failures create extra investigation work and make it harder to distinguish a product defect from a problem in the test itself. AI-generated test code can contain these weaknesses, so a single successful execution provides limited evidence of reliability. Teams should check whether tests behave consistently across repeated runs and investigate recurring failures. Otherwise, time saved during test creation can be consumed by maintaining unreliable tests. What should a company check before committing to an AI testing tool? A company should examine how easily it can retrieve and reuse its testing assets if it changes tools. Important questions include whether test cases, results, requirement links, and change history can be exported in a usable format. For generated automation, the team should establish whether the code can run and be maintained outside the vendor’s service. It should also identify features that depend on proprietary components or continued subscription access. A practical evaluation can include exporting a small sample and checking what another tool can actually read. This helps estimate the future effort of migration and protects the value of the team’s work.
Read
AI in GxP Environments: From Pilot to Validated Deployment
Misclassifying a document can cause an important record to be filed in the wrong place within a system. In the pharmaceutical industry, such an error has implications for data integrity and the handling of regulated documentation. This was one of the examples discussed during the “Deploying AI in the GxP World” webinar, illustrating how many decisions need to be made before artificial intelligence can support day-to-day work in a GxP environment. On 13 October 2026, we attended the “Deploying AI in the GxP World” webinar, organised by ISPE Poland together with ProductLife Group (PLG). Naomi Ofili and Gabrièle Piaton from PLG spoke at the event. They discussed the risk assessment, validation and safeguards needed to move from an AI pilot to a deployment whose operation can be documented and assessed during an inspection. The webinar formed part of a series linked to the AI in Pharma 2026 conference. 1. What is GxP, and how does it affect AI deployment in pharma? GxP is an umbrella term for good practices covering areas such as medicinal product manufacturing, clinical trials and pharmacovigilance. One of the webinar’s central messages was that assessing an AI application should begin with its intended use and impact on a specific process. The same model can support tasks with very different implications for product quality, patient safety and documentation. The speakers illustrated this through translation. Translating internal correspondence and translating product information submitted to regulatory authorities require separate assessments. The same applies to literature analysis: the requirements depend on whether the search supports market monitoring or the identification of information about medicine safety. How the AI output is subsequently used also matters. Text, classifications or metadata may become part of regulated documentation. The assessment should therefore consider the solution’s role in the process, its impact on GxP records and the consequences of an error. The speakers recommended carrying out this analysis when developing the project’s business case, so that the validation scope, resources and costs can be identified early. 2. AI validation needs to be planned across the operational lifecycle Validation provides documented evidence that a system is fit for its intended use. The webinar repeatedly returned to the question of how to demonstrate this suitability for AI. The speakers referred to the risk-based approach described in GAMP 5 and to guidance on artificial intelligence. The materials cited included the ISPE GAMP Guide: Artificial Intelligence, published in 2025, which addresses AI-enabled systems in GxP areas. Another reference was the European Medicines Agency’s reflection paper on AI in the medicinal product lifecycle. The practical questions concerned data and evaluation criteria. Do the test examples reflect real documents and products? Was the test dataset independent of the data used to tune the solution? Which results will we consider acceptable, and did we define these criteria before testing began? The approach presented also covered limiting outputs unsupported by source material, assessing behavioural stability, monitoring performance, handling invalid inputs and detecting bias. Testing before release was combined with controls during operation and assessment of the impact of model changes. Reference collections of test cases developed with subject matter experts, described during the presentation as golden sets, can help. Revisiting the same cases across successive versions of a solution makes it possible to check whether a change has reduced performance on tasks that matter to the organisation. We explore practical ways to support testing and quality documentation in our comparison of AI QA tools for pharma. 3. Human oversight extends beyond approving an output Naomi Ofili distinguished between two levels of human involvement. The first is human-in-the-loop: a stage in the process at which an expert approves, edits or rejects an AI output. The second is oversight across the solution’s entire lifecycle, including monitoring, preventing uncritical acceptance of automated outputs and the ability to stop the system. In the workflow described, the AI output underwent automated checks before being reviewed by a designated expert. Information about the sources, instructions given to the model, its version and the approval was retained. This record made it possible to reconstruct the conditions under which the output was produced and identify who approved its use. The expert also helped define acceptance criteria and develop test cases. Their knowledge therefore informed the solution’s design and the way its quality was assessed. For a company planning a deployment, this means assigning responsibilities and allocating time for expert involvement from the outset. 4. What did the examples of literature monitoring, translation and data migration show? The speakers illustrated these principles with three examples from projects carried out by the PLG team. Each highlighted different requirements for assessing AI outputs and their subsequent use. 4.1. Literature monitoring for pharmacovigilance In the first example, AI supported the review of scientific publications for pharmacovigilance. The system proposed a category for each article and a rationale, both of which were reviewed by an expert. Gabrièle Piaton emphasised that a particularly challenging step was translating the specialists’ assessment method into a structured decision tree. This example showed the importance of documenting expert knowledge and classification criteria before automating a task. 4.2. Translation of regulated documentation The second example concerned AI-assisted translation reviewed by a human against quality criteria tailored to the risk associated with the document. The process also included reconstructing the formatting to facilitate the translators’ subsequent work. Assessment of the solution therefore covered content quality, the review process and the document’s suitability for further use. 4.3. Data migration and document classification In the third example, AI supported document classification, metadata extraction and mapping data to the target system’s structure. The speakers highlighted the difficulty of distinguishing between similar document classes and the consequences of misclassification. They stressed the need to trace data provenance, transformations and approvals, as well as to perform quantitative and qualitative verification before migrated data are put into use. 5. Hosting and costs should be considered before the pilot A separate part of the webinar focused on solution architecture. The speakers suggested deciding before the pilot where data would be processed, what information would be recorded in logs and whether the model version could be controlled. Their criteria for selecting an environment included confidentiality, data-processing location, update arrangements, the ability to reconstruct system activity and the cost of switching suppliers. The discussion also covered selecting models for individual tasks. Smaller, specialised models can help reduce costs if they meet the defined quality requirements. The proposed economic assessment focused on the cost of completing a task and obtaining the expected result. The speakers also highlighted the possibility of reusing components for information retrieval, testing, monitoring and output approval. We discuss the division of responsibilities between a pharmaceutical company and its supplier, along with update controls, in more detail in our article on SaaS validation in pharma and GxP requirements. 6. What helps move an AI pilot into day-to-day operation? Towards the end of the session, the speakers highlighted collaboration between technical teams, subject matter experts and the customer around a jointly agreed backlog. They also stressed the importance of appointing a business owner responsible for adoption of the solution and measurement of its outcomes. The experiences presented suggested a sequence of activities: defining the intended use and responsibilities, assessing risk, designing controls, building and validating the solution, and then maintaining it. Decisions about data quality, human oversight and change management affect every stage. For companies preparing a deployment, this means resolving several questions before the pilot: what task will AI perform, who will approve its outputs, how will their quality be assessed, and what will happen if the model or data source changes? The answers help teams plan the technical work, validation requirements and ongoing maintenance. 7. How does TTMS support deployments in pharmaceutical environments? Translating these decisions into requirements, tests and documentation requires collaboration between people who understand the business process, technology and quality assurance. At TTMS, we combine software development and maintenance for the pharmaceutical industry with TTMS Quality’s expertise in computerised system validation. Our validation services cover validation planning, requirements specification and review, test development and execution, results assessment and reporting. We use a risk-based approach and GAMP 5 guidance. The scope of work is tailored to the system’s intended use and the requirements of the specific process. If you are planning to use AI in a pharmaceutical process or preparing to take a pilot further, talk to our specialists about your solution’s requirements, risks and validation scope. Can an AI pilot in pharma start with synthetic data? Yes, synthetic data can help test an initial concept without using actual patient data or confidential documentation. However, they should reflect the structure, diversity and challenges of the intended application. Overly simple examples can give a misleading impression of the solution’s quality. It is worth including missing information, errors and ambiguous cases. The results of such a pilot are insufficient to demonstrate that the system is suitable for a real GxP process. Further assessment requires representative test data, agreed acceptance criteria and controls proportionate to risk. What should you do when AI and an expert assess the same document differently? The discrepancy should be reviewed according to an established procedure. The source document, AI output, solution version and the expert’s assessment and rationale should be retained. The cause may be a model error, ambiguous content or evaluation criteria that are too broad. Such cases help determine whether instructions, classification rules or tests need to change. An expert’s correction should not automatically trigger an update to a model used in a regulated process. Any change should be assessed, tested and approved, while retaining an independent dataset for quality evaluation. How should employees be prepared to use AI in pharmaceutical processes? Training should address the specific task, data and scope of the user’s responsibilities. Employees need to know what information they may submit to the system, how to check outputs and when to raise concerns. Exercises involving incorrect, incomplete or seemingly convincing responses are useful. They help assess whether users can verify an output rather than accept it uncritically. Instructions for handling failures or periods when the solution is unavailable are also helpful. Team preparation should include an assessment of practical skills, and training should be updated when the system or procedures change.
Read
GPT-6 Cyber: What OpenAI’s Cybersecurity Model Means for Business
OpenAI has introduced GPT-6 Cyber, an AI model designed for cybersecurity work. For companies managing customer portals, payment services, and internal platforms, potential benefits include faster vulnerability investigations, more frequent security reviews, and better support for engineers preparing and testing fixes. Its practical value will depend on whether it helps teams confirm vulnerabilities and test fixes while reducing the time specialists spend on those tasks. What Is GPT-6 Cyber? GPT-6 Cyber is positioned as OpenAI’s specialized model for cybersecurity work. Before its introduction, BusinessToday reported that selected customers were testing an alpha version through Daybreak Red. According to Investing.com, citing Fortune, OpenAI is also developing a separate product to help customers deploy GPT-6 Cyber securely, automate security tasks, and patch vulnerabilities. The product would give OpenAI greater oversight of how its models are used. For businesses, this raises practical questions about how the service would fit into existing security operations: which tasks it could carry out, which actions would require approval, and what information OpenAI would receive about its use. These details would influence both implementation costs and the suitability of the service for handling sensitive company systems. There is already a documented foundation for this approach. OpenAI describes GPT-5.6 Cyber as a model for approved users conducting advanced vulnerability research and security testing. It also offers Codex Security, an application security agent that helps teams investigate vulnerabilities and prepare fixes. These products show how OpenAI already supports security work; GPT-6 Cyber needs its own assessment of capabilities and performance. For a buyer, three parts of an AI security solution deserve separate attention: Part of the solution What it determines What the business should verify Model The analysis and reasoning available for a task Accuracy on relevant security cases, limitations, and cost Access program Who can use particular capabilities and under which conditions Eligibility, approval requirements, and permitted activities Application and integrations The data the system can inspect and the actions it can execute Supported tools, permissions, review controls, and audit records Before purchasing access, check how the solution will connect to the company’s code repositories, monitoring tools, and process for approving changes. Why Cybersecurity AI Matters to Business Leaders Security work competes for engineering capacity. Investigating a suspicious code change, checking a supplier’s advisory, and validating a patch all draw on people who also maintain applications and deliver new features. AI creates an opportunity to move some of the research and preparation into a repeatable workflow, allowing specialists to spend more time on judgment, validation, and decisions about production systems. Faster security work can also help companies keep their services running. A retailer may need to secure a checkout integration without disrupting sales. A manufacturer may need to understand the consequences of updating software connected to operational processes. A financial services company may need clear evidence of what was investigated and how a problem was resolved. In each case, useful automation must fit the business process surrounding the software. OpenAI’s broader investment shows the importance it assigns to this market. On September 3, 2026, the company announced a $1 billion commitment covering subsidized Daybreak access, training, technical support, and partnerships for organizations protecting essential services. Four Business Uses to Evaluate for GPT-6 Cyber The following scenarios are our analysis of where a cybersecurity model could create value. They are proposed evaluation areas whose suitability for GPT-6 Cyber requires testing. Each depends on the capabilities, tools, and permissions available in the eventual deployment. 1. Investigating Vulnerabilities in Business Applications A useful pilot could focus on a small set of applications with a clear business owner. The model would be given approved code and architecture information, then assessed on whether it helps explain suspected weaknesses and identify the evidence needed to confirm them. For example, a team might investigate whether a customer portal consistently enforces access permissions across related services. The business benefit would come from reducing the time needed to reach a defensible conclusion. A helpful result should identify affected components, explain the conditions under which the issue matters, and make it easier for an engineer to reproduce the problem in an authorized test environment. 2. Preparing and Testing Security Fixes Once a vulnerability is confirmed, the next task is to prepare a change that addresses it. A security AI workflow could help draft a patch, identify related code paths, and propose tests for both the security issue and normal application behavior. Existing Codex Security documentation already describes workflows for reviewing changes, validating findings, and preparing fixes, making this a concrete area for evaluating future model improvements. For the business, success means less engineering effort per validated fix while maintaining release quality. Engineers should still review the change and run appropriate tests before it reaches production. 3. Prioritizing Work Using Business Context Using an up-to-date list of systems, their owners, and supporting documentation, an AI system could help connect technical findings with business consequences. This could help the team decide which vulnerabilities to fix first and who should handle them. 4. Helping Teams Investigate Security Incidents Another use to test is building an incident timeline from security alerts and system logs, with internal procedures guiding the investigation. An evaluation could test whether the model links its statements to evidence, distinguishes observations from hypotheses, and identifies missing information. This scenario would require suitable integrations; it should not be assumed to be a built-in GPT-6 Cyber feature. A useful output could help the next analyst continue an investigation or help a service owner understand the affected business process. Decisions such as disabling accounts, blocking traffic, or isolating systems need explicitly assigned authority because they can interrupt legitimate activity. What Could This Look Like in a Customer Portal? Consider a company preparing a new version of a customer portal connected to its order management system. A security review flags a possible weakness in how the portal checks access to order details. In a controlled pilot, an AI system would receive the relevant code, a description of expected permissions, and test accounts containing fictional customer data. The team would assess whether it can help trace the affected logic, produce a clear explanation, and propose a test that demonstrates the problem. If the finding is confirmed, engineers could evaluate its suggested correction and additional regression tests, which check that existing functions still work after a change. The final result should be a reviewed change with evidence: what was wrong, what was modified, which tests passed, and who approved the release. This would require access to the relevant code, a test environment, and a process for assigning confirmed issues to engineers. How to Measure the Business Value of GPT-6 Cyber A pilot should compare the AI-assisted workflow with the team’s current process using comparable cases. Include confirmed vulnerabilities, issues previously dismissed as false alarms, and cases where the evidence is incomplete. Record analyst review time as well as model execution time. An answer produced quickly can still require substantial investigation. The following measures provide a practical basis for a decision: Measure What to record Why it matters Time to assess a suspected vulnerability Elapsed time and analyst effort needed to confirm or dismiss an issue Shows whether the workflow accelerates investigation Finding quality Confirmed findings, false alarms, and missed issues in a reference test set Reveals whether apparent productivity comes with additional errors Time to a tested and approved fix Time from confirmation to a tested, approved correction Connects AI assistance to remediation Engineering effort Hours spent reviewing, correcting, testing, and documenting outputs Makes supervision costs visible Total cost per resolved case Model use, tools, test environments, integration, and staff time Supports a realistic decision about scaling For example, if a pilot saves analyst time but generates extra work for developers, both effects belong in the assessment. If it uncovers more valid vulnerabilities, the organization also needs capacity to fix them. Access, Pricing, and Deployment Questions for Buyers OpenAI’s existing Daybreak documentation requires appropriate organization approval and project access. It distinguishes access to a program from access to a particular model. For GPT-6 Cyber, organizations should verify the applicable requirements directly, including whether access is limited to an evaluation or supports the planned production use. Commercial evaluation should cover pricing, usage limits, supported integrations, and the handling of company data. Teams should establish what source code, logs, and configuration information would be processed; where processing occurs; how long data is retained; and which contractual controls apply. Availability through a particular cloud provider or within an existing subscription should be confirmed for the specific offering. A pilot budget should include implementation and review costs alongside any model usage fees. How to Keep AI Security Work Under Control A business should define the scope of an AI security workflow as carefully as it defines the scope of an external security assessment. Specify the systems it may inspect, the information it may access, and the actions it may take. Separate permission to analyze a problem from permission to change a live service. OpenAI’s published Daybreak guidance recommends isolated environments, monitoring of agent actions, and enforced limits on authorized activity. For an initial business pilot, that supports a controlled test environment, narrowly scoped credentials, review of proposed changes, and records that allow the team to understand what happened. The operating process also needs an owner. Someone must review unresolved findings, decide when additional evidence is required, and stop a workflow that behaves unexpectedly. Training should cover how to challenge an AI-generated conclusion and how to recognize when the system lacks enough information to proceed. Where Businesses Should Start Start with one application and one recurring security task, such as investigating suspected vulnerabilities or testing fixes. Assign someone to review the results and agree how you will measure accuracy, time saved, and the effort required from engineers. A focused pilot can help establish whether the approach is useful enough to expand. Considering AI for your company’s security processes? Talk to TTMS about the task you want to improve, the systems involved, and your data requirements. Together, we can explore a suitable approach and define what a useful pilot should demonstrate. Discuss your AI use case with TTMS How is GPT-6 Cyber different from using a general-purpose AI model for cybersecurity? GPT-6 Cyber is described in published reports as a model focused on cybersecurity, with early testing through OpenAI’s Daybreak Red program. General-purpose models can also assist with security tasks, such as explaining code, reviewing documentation, and analyzing supplied findings. The question for a business is whether the specialist model produces more accurate, useful results on the tasks its team actually performs. Its name alone does not establish that advantage. A meaningful comparison should give both models equivalent information, tools, and time, then have security specialists assess the results. Published evaluations can help inform that comparison, but results from another model should not be attributed to GPT-6 Cyber. Can GPT-6 Cyber replace a cybersecurity team or an external security provider? A company should retain qualified people responsible for assessing risks, validating findings, and approving changes. A model’s analysis depends on the information and tools available to it, which may leave gaps in its understanding of the company’s systems. Security specialists also consider operational priorities, investigate ambiguous evidence, and coordinate the response when something goes wrong. AI assistance may reduce the effort needed for particular tasks, but that needs to be demonstrated in practice. For a business using an external security provider, a useful discussion is how the provider validates AI-generated work and whether any time savings improve the service. Responsibility for protecting systems and resolving problems should remain clearly assigned. Is GPT-6 Cyber useful for a company that mainly uses software from external vendors? Its usefulness would depend on what the company controls and what information it can access. A business using standard cloud applications may have limited visibility into the vendor’s underlying code. Its own responsibilities may include account permissions, configuration, integrations, and custom extensions. Those areas could provide relevant tasks for AI-assisted analysis, subject to the model’s verified capabilities and the available integrations. Before testing, establish which systems the company is authorized to assess and what requires the vendor’s involvement. Findings affecting the vendor’s product should be reported through its security process so that they can be investigated and addressed. Does an AI security review that finds no vulnerabilities mean an application is secure? No. A review can miss vulnerabilities because of incomplete information, limited test coverage, or errors in the analysis. A finding-free report should therefore describe what was examined, which tests were performed, and what remained outside the scope. For example, reviewing selected source files does not establish that the application’s production configuration and access permissions were also checked. The result should be considered alongside other security evidence, including testing and specialist review appropriate to the application’s risk. Record unresolved questions and limitations so that a clean report does not create unjustified confidence. How should a company assess a supplier offering “GPT-6 Cyber-powered” services? Ask the supplier to explain which model it uses, how it accesses that model, and which parts of the service rely on it. Request a demonstration using a representative, authorized task and ask to see the evidence supporting the findings. Establish who reviews the output, who implements corrections, and what happens when the analysis is wrong or incomplete. The service description should also explain how company data is handled and which actions require approval. If the supplier changes the underlying model, ask how it checks that the service still meets the agreed requirements. Evaluate the offer against clear deliverables, such as validated findings and tested fixes, with named people responsible for the work.
ReadThe world’s largest corporations have trusted us
We hereby declare that Transition Technologies MS provides IT services on time, with high quality and in accordance with the signed agreement. We recommend TTMS as a trustworthy and reliable provider of Salesforce IT services.
TTMS has really helped us thorough the years in the field of configuration and management of protection relays with the use of various technologies. I do confirm, that the services provided by TTMS are implemented in a timely manner, in accordance with the agreement and duly.
Ready to take your business to the next level?
Let’s talk about how TTMS can help.
Sunshine Ang Sen Shuen
Sales Manager